Good points.

This whole "buffered delete" depends on how long you can expect your end user to leave the changes uncommitted.

I lean towards the Draconian and would probably FOPEN('TheFileYouClaimToWantToDelete', 12) to lock the file when the user selects it for deletion. If it can't be locked, it's in use, and then toss up a notice to the user informing them they are trying to delete an open file.

---J

>Nadya,
>
>I guess that depends on how long a user session lasts, and whether files by these same will ever possible exist again. IOW, if a user "deletes" a file, then wants to create a file by the same name while your file manager is still open, there could be a problem.
>
>Also, a user may make a change to a file another user has marked for deletion, then 10 minutes later find out the file is gone. Or someone may manually deleted a file someone has marked for deletion (but easy to overcome...simply check for file's existance before trying to delete it at form close).
>
>If these are not possible issues, Jason's idea is a good one, and easy to put in place.
>
>>I think, Jason's idea is the simplest one. When I press delete button, I can store recno() in a cursor. Then in form's release method I can check for these records, if the record is deleted, delete files. Seems like a cheap and easy solution. I don't see downsides at the moment. Do you?
>>