>>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
Vicki Combs
Customized software for today AND tomorrow...
Applications and web sites designed, developed and maintained. (MBE)
"Change is inevitable...unless that's changed!