Hi Vicki,

First thought: if the Save methodology before the TABLEUPDATE() uses an INSERT INTO statement and does NOT specify the fields inserted (something like an INSERT INTO MyTable VALUES ...), then simply by adding a field to the table you'll break the Save because the number of fields will have changed and the number of VALUES passed doesn't match. I've gotten the "uniqueness violated" message in this instance several times, most often when I've added a field that's the same data type as the primary key (why that last part is, I don't know).

Other thoughts: make sure the data type of the new field matches on both ends, and make certain that null values in the new field aren't messing you up.

HTH.

>Don't you hate it when you have an application that was running like a top and you make one little change and bam, the whole thing goes crazy! Here's my story: I added a field to a table in the user's application. I added it to their database and the screen. I added it to the view for that screen. Tested it with a copy of their data and added the new field info works great. Problem occurs when I try to add a new record using tableupdate(0,.T.,theview,amyarray). I keep getting a uncommitted changes error on the view and the error message is an 1884, uniqueness of index violated. I've looked into the file, checked the primary keys, checked the primary key generation, etc. and it looks like the system is creating a record with a blank key and putting the key into the PREVIOUS record (physical).
>
>I swear, I did not change anything in the modify/save areas, only added the one little field. Anyone have a clue where I might look to figure this out or how to fix it?
>
>TIA,