No triggers on deleted records

[Olaf Doschke]

This is a minor problem, so I don't need a solution.

If you work with SET DELETED OFF you can eg UPDATE/REPLACE or edit deleted rows in a browse, but neither the table rule, field rules nor the update trigger run.
If you recall a deleted record the field rules, table rule and insert trigger runs.

These two facts mean recalling a record can be hindered, if a record is updated against any rule while being in its deleted state, ie you delete a row, modify it against rules and then a recall triggers rule errors, before the insert trigger runs and finally allows the row to be undeleted again.

It's obviously no big use case to work on deleted rows, also buffering can be used to overcome this. That's what's making it a minor problem only. Most probably this is by design, as typically you don't want rules checked for deleted data, also triggers typically used for referential integrity checks should never error on deleted rows.

The obvious question: Is there anything, which would get triggered for deleted rows? I would of course be able to monitor file changes even outside of Foxpro with very low level file system hooks, since the changes in deleted rows are of course written to disc.

Could we perhaps somehow hook into the automatic locks done on DBF files during writes?

Bye, Olaf.

 

[Mike Lewis]

Very interesting, Olaf. On first reading your post, I thought the behaviour was the opposite of what you would expect. On reflection, it's probably correct. I wonder if it's documented anywhere.

As far as your obvious question is concerned, I don't have an obvious answer, but will give it some thought.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Thanks, Mike.

It just surprised me a bit, as it can break a RECALL, even if you don't intentionally change a deleted row, but the rule of the table changes, for example.

RECALL is a seldom operation anyway, unless you do record recycling and for that matter you only need to harden your recycle process to either blank data before a RECALL or do this only buffered. BLANK DEFAULT helps a lot, even better BLANK DEFAULT AUTOINC to address auto incrementing fields too and make it even close to an APPEND BLANK.

The recycle process is in a single place of the code (in my case at least). Any defaults breaking rules are a matter of good table design and even if that is problematic you can populate the record buffered anyway. So it's not a big thing.

Bye, Olaf.

 

[Mike Lewis]

RECALL is a seldom operation anyway

That's right.

Way back in my early dBASE / Foxbase days, I would give users the option of seeing "deleted" records, and of "undeleting" any of them. I soon realised that that was a terrible UI design. Now, when someone deletes a record, it stays deleted. The only time I ever use RECALL is when I'm messing around in the development environment, and even then only rarely.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads