Vicki,

Okay, so much for first thoughts (g) ...

I'm assuming that the new field has NOTHING to do with the table's primary key in any manner, or any other default-value fields (ie, this code was successfully performing the TABLEUPDATE() before you added the new field that caused it to sneeze).

Have you SUSPEND-ed just before the TABLEUPDATE() and checked your environment to see if the new row is correctly in the buffer, or maybe even doing another APPEND BLANK with some dummy data from the command window at that point? There might be a SET command out of sync, the table might be locked or unavailable, or the operation might be timing out for some reason.

Apart from that, and the null or mismatched data type, I'd have to look at the code directly to come up with anything else. Should you choose that, please make a PKZIP file and attach it to an e-mail sent to evan@flextech.net -- I'll look at it tonight or over the holiday.


>>>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).
>
>Nope, I'm using a straight ole "append blank" here because the code in this section is very generic. I could write a case statement for all of the screens and use that to create an "insert" statement with fields and values but it seemed easier (?) to append blank and then replace.
>
>I'll look into the field type part, tho. I'm fairly sure the new field is just a character string and is such through out the program but... who knows <g>.
>
>Thanks