Hi Yvonne, I would first check all scripts which allow deletion and make sure they either are fired from button on layout based upon the table occurrence they should be deleting or that they include a go to layout first. Then I would check all GTRR steps. If go to related is fired and there are no related records, script can continue and delete the parent record it is sitting on. Then I would check all portals with button to delete and make sure it says delete portal row and not delete record. Corruption usually doesn't present as you suggest; it sounds more like something is deleting them. :smileyhappy:
That's the odd thing. According to Inspector, there is only one script that uses that table and it doesn't delete anything. And the table is pretty insular so there are no GTRR scripts that go to it, nor is the data used in a portal row anywhere. And it does not display any data via a portal row either so I know it isn't the 'delete portal row' problem. It has one delete button and I'm the only one with access privileges to delete in that table. And I'm using custom menus so the 'delete record' is not available via the menu bar either. I've triple-checked all of this, which is why it is such a mystery. I was expected to find something I had overlooked in the programming but have not yet come across it.
I appreciate the response and will go back and check everything again today. I would love it to be something I overlooked since then I don't have to worry about data integrity.
Just throwing out a possibility here....
Is it possible that the record is being overwritten instead of deleted?
Two possible scenarios:
- An import records uses an update matching option to overwrite the data with completely different data
- A user enters data that unknowingly changes the values to the point it no longer "looks like" the same record.
In light of your two file structure, you might check to see if each Table Occurrence in your interface file points to the correct table in the data file as that might explain a possible "item 2" scenario.
There is the other much more frightening possiblity that your access has been compromised.
Well, thankfully this was not a security breach. Nor was it a damaged file. It was a broken script that was going to related records via a specific layout in another file that would then delete a record. The layout it was going to was inadvertently deleted so instead of deleting the record from the corrent table, the go to related records step was landing on a layout for a different table. Since the scripts didn't invoke the problem table, it wasn't showing up in the Analyzer report as being dependent on that table. I finally looked at all the problems in the solution and found the 'unknown layout' in a script. Fixed that and the problem has resolved.
Thanks for the various suggestions.
Go To Related Records is a very useful tool, but which is very poorly documented and some of the gaps in the documentation can be hazardous to your database. To learn more about GTRR, click the following link:
The Complete Go To Related Record
Thanks for the link; I'll check it out.
Well, thankfully this was not a security breach. Nor was it a damaged file. It was a broken script that was going to related records via a specific layout in another file that would then delete a record. The layout it was going to was inadvertently deleted so instead of deleting the record from the corrent table, the go to related records step was landing on a layout for a different table.
This is the reason that error trapping is so vital ... and to trap on EVERY script step and not just a few. Whether there were no records when evoking a GTRR (or more likely no related record matching the FIRST record of a set) or whether the layout was accidently deleted (or corrupt), it could have been caught (and the script stopped) if Error Capture was on before the GTRR or layout switch. Many of these 'strange' mass deletions come from just such issues not properly trapped in the script so the script continues what it planned to do ON THE WRONG layout (which usually means the wrong table occurrence). The results are disasterous.
We had an in-depth discussion of the consequences here
I provided a script on that post which showed how to protect (generally speaking) from unforseen issues like deleted layouts. I recall that, three days later, someone posted a comprehensive Error Trapping process expanding upon my concept and including a great process to log all errors.
UPDATE: Yes, it was Matt P. here
By the way, I am guilty that, when providing a find script for others, I use error trap right before Perform Find and then test If [ not Get ( FoundCount ) ] or If [ not Get ( Last Error ) ] and neither really protect. I think we Developers provide those types of scripts because they are easier and because, as I indicated on the referenced post, each script should be treated as a 'special needs child.' But we are passing on improper error trapping techniques because of our laziness when we type.
I am pleased that Matt made it public where a lot more developers might see it and be aware of the risks and solutions.
Thanks, LaRetta, for the resource. Yes, I error trap but obviously nowhere near enough! I'm guilty of the same trapping you mention in your response. I'll get to work on that.