They're good for awhile after being written. We know it writes it because another screen shows records It blanks out the whole line (0 for numbers, including the AutoIncrement ID), after it had already written everything to that line. It often even is implossible due to further table and field rules. In the database,though, especially with 1:n related also firstly empty rows only having primary and foreign keys populated. Or always create DBF records first and load them into the view cursor with REQUERY, then act on the record and saving it can use the already generated autoinc id as key. If you want something working with views, use GUID. Values, then, beforehand you don't have an integer usable as foreign key or to distinguish two new not yet committed records. Only commits to the DBF are creating autoinc You can only rely on the native VFP runtime to act correctly on autoinc.īesides that, autoinc is bound to the DBF itself, when you append to a view cursor of an updatable view, the view cursor does not get populated from the DBF autoinc counter, especially in the usual buffered mode. Using a third party ODBC driver promising to be compatible with VFP8/9? Well, you proved it's not. The latest ODBC driver is VFP6, which had no autoinc, autoinc was introduced in VFP8, wasn't it?
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |