Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Recall+Tableupdate adding new rec, not recalling deleted
Message
From
30/09/2002 16:35:43
 
 
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00705037
Message ID:
00706132
Views:
24
Vlad,

Thank you for your help.

Cheers ~



>Hi!
>
>RECALL does not works well in views in VFP, as far as I know. In our application we usually have additional logical field called "IsActive" which we use for these purposes instead of deleted mark. This also a significant plus over RECALL when moving to other back-end in the future - most other back-ends does not have Deleted flag like in VFP table.
>
>>Hello all,
>>
>>I haven't been able to solve this one yet after two days, so I'm hoping for a hint or gentle nudge in the right direction from someone here with more experience with views.
>>
>>I am working with:
>>- An application designed for multiple users on a LAN.
>>- Tables with candidate keys and other fields.
>>- Views for each table.
>>- Forms based on the views.
>>- A common toolbar with typical buttons -- add, edit, mark as deleted, etc. Users can toggle the mark button to recall deleted records. SET DELETED is, therefore, OFF.
>>
>>Here is some partial sample code for a typical view definition in this project.
>>
[snip]
>>
>>What's happening as I test the app is this:
>>I am able to mark records for deletion just fine.
>>The interesting stuff happens after I recall a record.
>>It seems that here TABLEUPDATE() isn't finding the deleted record in the table and turning off the deleted flag. Instead, it ignores the existing deleted record, blithely adds a new non-deleted record with the same data as the deleted one, then complains that the uniqueness of unit_id candidate index has been violated. My code does none of that. I sit with the program suspended right before the tableupdate and there are 1182 records in mytable. I "step" with the debugger, the tableupdate line executes, and reccount(mytable) becomes 1183.
>>
>>The view's UpdateType is definitely still (1) right before my TABLEUPDATE(). In fact, I can edit and save records in the app just fine; no duplicate, index-violating records are created during those functions. The creation of new duplicate record (and subsequent index violation) only occurs after TABLEUPDATE() following a RECALL.
>>
>>Please, could someone help shed some light my way?
>>
>>~ Many thanks in advance ~
Bill de Veas
Previous
Reply
Map
View

Click here to load this message in the networking platform