troubleshooting corruption: rel records vanishing?

[ESpringer]

Records created via a portal (quote records via relationship from a source record) started to vanish today.

I went troubleshooting the relationship (both in the same file), and found that it seemed set up right, and was still treating old records correctly. Records created directly in the related quotes table seemed to be stable. (The solution had been in use for months, one of my first FM7 creations.)

So, I created an external table, and had it import all the quotes table records. I set up an "allow creation" path in my main file to the new table and then redirected the portals in my source layout over to the new external table, to see if it would help. I went merrily creating records in the new table via the portal.

But what I just witnessed was the clincher (I think) for corruption: I opened the new external table in table view, admiring the records I had just successfully created via portal. It all seemed to be intact and behaving. But at some point when I tried to modify some data directly there, FM complained that the records were in use elsewhere (odd), so I went and closed the main file (with the portal via which these were created). As the other window closed, I literally saw 40 table rows disappear before my eyes, and both the Found and the Total count reverted back, counting only the old set that I had imported as the starter set for the table. Finds for words that I knew were part of newly created records turned up nothing.

So, questions: this really is corruption, right? If so, should I assume it's in the *main* source table, since the quote records that it generated in the new file had the same problems as the quote records recently generated in the intra-file table? Is it worth simply deleting the *portals* from which data was generated -- could the portal be the explanation for the unstable new records? Is it generally safe to import *data* from a bad file into a cleanly-created table, or could structural corruption hide within the *data* that I exported from the old quotes table to the new external one? Are there ways to confirm the location of corruption and/or to check whether it's present in a given earlier version without just running experiments with each restored file? (This one's particularly awkward, because the new portal-created records *do* seem to get created and behave properly for several minutes.)

Thanks!

[-Queue-]

Just curious. Does the relationship have 'Delete related records' allowed?

[ESpringer]

No - I had seen others (or you?) mention "allow deletion" as a potential factor in corruption, but in this case, no...

BTW, I just tried creating the records via an entirely distinct portal on a distinct layout (in main file): same symptoms!

[-Queue-]

This may be dumb, but I wonder if it has something to do with committing records. What if you add new records in the portal, click a Commit button (just for kicks) to commit the parent record, which should commit all the related records. Then open the external file with your new records showing, and then close the main table. What happens then?

[ESpringer]

Same result. Assigned one-step "Commit" script to button on main record, hit it after dragging stuff to the portal to generate the related records. Viewed healthy-looking records not only in portal but also in related file table view. Tried to modify a value in table view, got "already being used by another file, or insufficient privileges" type message. Closed main file, new related records vanish in their own table before my eyes...

[-Queue-]

Very odd. I would think corruption, but it also sounds like a bad file reference may be involved. Not that I've ever seen a bad file reference (if such a thing exists).

What if you close the related file first and then close the main file. Are the records still removed? What processes run on closing the main file?

[ESpringer]

The original problem was happening in the same file, across tables. I only created the new file (and a new file reference) in order to troubleshoot. So it would be quite a coincidence if file reference were the issue, no? (Unless there is corruption in how table references are stored... but the records *are* showing up in the right table initally!)

As to your second suggestion: at first the records were disappearing without the related file ever being open, and without the main file closing; I only opened and closed in process of tracking down problem. At any rate, if I close the main file after creating the related records via portal, the related records aren't visible in the same portal when I reopen. Needless to say, they're not in the external file, either.

[-Queue-]

I would send the files to FMI. There's something seriously wrong here.

[ESpringer]

Update: I believe I've discovered that this problem is not specific to my file at all. It's a problem with portal-generated related records, at least those created using drag-and-drop from another application on Mac OS X, FM7. (I don't think it happened in 6; I remember being so pleased with drag-and-drop into allow-creation portals as a great way to pull related snippets into FM.) Anyway, I've started a new thread since the problem is a more general one.

http://www.fmforums.com/threads/showflat...true#Post122514