How do you deal with User deletion of records 1

[foxrainer]

Would like to ask a general quesiton with, hopefully, many answers:

In a DBC with several related tables, how do you let a user 'inactivate' a record?

I.e.: A record is created, the user realizes creation was in error, and therefore needs to be 'eliminated'?

In the past, I did use a 'Delete' button which actualy marked the record for deletion, then, packed with a general 'interval packing' program (seperate program usually running on the server at night if all are logged off).

However, I am thinking: Isn't taht a bit risky of having records deleted by mistake?

Any thoughts?

Thanks in advance

 

[ramani]

HI
1. Setting relation is not a problem to delete a record.
2. If the records are having referential integrity, that the record shall not be deleted.. if related table contains a record with this key reference.. then, either you can set the referential integrity and dont allow the record to be deleted. Even without referential triggers.. you can put the code under your delete button, to check the child tables record existence and fail the delete attempt.
3. REgarding packing of the deleted records, your approach is fine. If needed, you can collect the deleted records in a table noted as myFileDel (same name as the file packed+"Del&quot and then pack the original table. The myFileDel can be again deleted periodicaly.. say every month.. to ensure that in case you need to go back and check integrity.. you can do that.

Hope this helps your thinking ramani :-9
(Subramanian.G),FoxAcc, ramani_g@yahoo.com

 

[DBRANDON334]

I make it a practice that when I delete a record I BLANK the record also. this way it is not included in any queries etc. I don't reuse records so my nitetime job searches the dbf's for a blank key field, deletes it and then packs.
Dave

 

[foxrainer]

Ramani and Dave,
thank you very much for the help. I do currently export records to a 'Deleted' table, which I will continue doing.

I utilize a field in each table named ' marked ' which noteds if the record was deleted, exported, imported, etc, etc.

Thanks again

Rainer

 

[dgrewe]

My approach to the problem is a little different.
For every "CRITICAL.DBF" in the system, I have an audit dbf.
I.E. CUSTOMERS, CUSAUDIT.
The structures between them are identical.
When anyone makes a change to the CUSTOMER.DBF I record the change as a new record in the AUDIT.DBF also.
Both dbf's have 3 fields
UPDATE (L)
UPDATEBY (C 12) = Username
UPDATED (DateTime)
When a record is requested to be deleted by the user. A copy of the record is made to the audit table. Then the program Blanks out all the fields and then marks it for deletion in the CUSTOMER table. A New record request looks for a blank deleted record with a deleted index.
The AUDIT table acts as a WHO DONE IT and in the event of an emergency where the CUSTOMER table is damaged. The AUDIT table has a Index on it that allow me to recreate the CUSTOMER.dbf with the last know record action.

I also use this in systems that do not have the nightly maintenance time available. David W. Grewe
Dave@internationalbid.com

 

[foxrainer]

David,

that sounds like a very good idea. I write mainly medically associated programs (because, primarily, I am a PA) and I will have to make compliance changes to most of my programs (natial compliance to patient confidentiality).

Currently, I only have records added to a 'changed' table, with the user name, number, datetime(), field name changed and a couple of other fields, such as, was the field edited or viewed.

I, however, like your approach of copying the whole record as it can be used to compare and possibly retrieve previous data!

Nice idea, simple, and it works!

Rainer