Hi Bob,

Thanks for the reply. Yes, I also check the update criteria for the UID field in the view also (learned that quickly the hard way).

But the issue here is the default value property of the UID field. It seems to randomly disappear from the view definition so for new records in the view doesn't get a UID. This of course affects future modification/updates to the record and can also cause primary key conflicts (two UIDs with value = '').

The reason I do it this way it to always have the UID available immediately after creating a record. If I put the UDF in the table (or use autoincrement) then I have to requery the view and determine which was the new record to get access to the new UID.

How do others do it?

Ken


>Hi Ken,

>Not sure if this is the problem, but check your view and check the Update Critera tab in the view designer. Be >sure the unique ID column is checked in the update column (the one with the pencil in the header) to indicate >to update this column on the underlying table.


>>Hi All,
>>
>>I have occasionally had this problem and just wanted to see if others have had similar experiences and know any reason/solutions :
>>
>>For my projects I almost exclusively use views for IO. I have also use a UDF to create a unique ids for tables. I add the UDF to the default value property of the unique key for each view. Thus, when I create a new record in the view, it gets the new id which then gets written to the table when I do a tableupdate. It is then used to update/modify the values of the view when changes are made.
>>
>>Every once in a while I get a call because the tableupdate is not working. When I investigate, it turns out the default value property for the unique key is empty. It seems like the DBC just loses the property value.
>>
>>Everything else is fine, no table or DBC corruption, just the missing defaults.
>>
>>Any ideas?