Files loosing relationship key

[merkaba22]

In a three year old FM database there are portals for data entry within a parent file and this design has been working fine until recently.

Now, in at least two instances, the relationship key data in the child (portal) files have been lost/corrupted and the data no longer displayed in the parent file portal; if the keys are manually corrected, the data displays as it should.

I suspect some form of file corruption -- and I wonder if this is a good time to "rebuild" the solution and, if so, what the preferred method for this would be.

I am using FM 10 but could upgrade to FM 11 if it would help.

Thanks in advance.

[bcooney]

Can you describe the relationship in more detail? What fields are you using for keys and what is the match?

[merkaba22]

I looked at the file again this afternoon and found scripts not running as intended and not being able to click in fields that otherwise are defined appropriately -- even newly created fields. I am quite confident that the relationship keys are not the real issue.

I am looking for a specific method to create a new file, copy over the layouts and field definitions, and, if possible, the relationship mapping to ensure that there is no corruption ... whereupon I can import the data for the various tables, etc. and restore the solution and its data to a fully working version that existed prior to a few days ago.

It was my understanding that this was possible with FM 11 -- I am looking for that specific technique.

[bcooney]

I assume that you do not have a "golden" clone. That is, a pristine version into which you could import the data. Correct?

If you believe that the file that you have is corrupted (and I would need to see it to agree bcs your descriptions of the problems don't confirm corruption), then copy/paste is not a good idea. If done, you should test after each step to ensure that you're not reintroducing corruption.

Even importing data from a corrupt copy can be a problem, as the data could hold the corruption. However, there are no special tools in FMA11 that didn't exist in FMA10. You list your skill level as "Advance," and so where are you stuck with the import of tables, layouts and data?

In what version of FM was this file originally written?

[merkaba22]

The client does not have a "golden master".

I read here last summer (and searched for and did not find) about a procedure based on additional features in 11 that would make such a rebuild easier -- I am looking for that.

When I evaluated the solution, I created a new test field and added a checkbox along with appropriate settings and could not modify the field -- on my personal copy, I could.

Data entered in portals disappeared and scripts for deleting each line item failed within a few minutes of entry, etc. whereas a week ago none of this was happening.

The host Mac Mini has not been maintained in years, has way too little RAM and is used for other purposes against my recommendations/economic considerations outside my control.

I seriously suspect the Mac is the cause and want to rectify the DB asap.

[bcooney]

"When I evaluated the solution, I created a new test field and added a checkbox along with appropriate settings and could not modify the field -- on my personal copy, I could."

Huh? So you have a copy of the system that works, and if it's put on the FMS (that isn't setup as per FMI's recommendations), it fails.

[merkaba22]

I did some work on a legacy system some time ago where I copied the file to my Mac.

In witnessing the aberrant behavior on the subject file the other day, I showed the client the issues I faced by creating new fields as described above on the old (less developed) copy wherein it could be demonstrated that in the old FM the solution worked correctly and, now, only within sometime in the past 7 days, since I last visited the client for a few minor mods, the solution is working improperly as described above.

I hope that clears that up.

None the less I, since I do not claim to be all knowing, would like to revisit the technique for recreating the file without re-writting it from scratch that I read about earlier this year and have never used.

If there is some other way to "de-corrupt" a file, other than the built-in tools FM offers, I would be very appreciative all positive suggestions.

[Vaughan]

There are no tools to de-corrupt files. The recover command's job is to salvage the data, and it does this at the expense of the file structure itself if necessary. So it will happily delete parts of scripts or layouts to fix the data.

It does this because the data is the most valuable part, and the most difficult to reproduce.

AFAIK there were no fancy database re-build features introduced into FMP 11, other than the ability to copy and paste custom functions.

[merkaba22]

Thank you for that -- is there a methodology where a file can be recreated by copying over layouts, importing tables (with fields definitions, etc) and relationships before, as the last step, using the script importing feature that has been part of FM for some time now?

Is there any information I can review?

[Vaughan]

The only "methodology" is the order of doing things which makes the least amount f work.

It's something like custom functions first, then tables, then layouts (empty) then scripts, then the layout objects.

As Barbara said, copying and pasting stuff out of the old database might re-introduce the corruption. I've personally seen simple graphics on layouts that caused the application to crash.

So like Dirty Harry asked, are you feeling lucky?

[merkaba22]

Well, thanks all for the tips -- I suppose that I could go back to the last saved DB prior to my recent but minor mods, and re-do the work with the hopes that that will remove the source of corruption (since there is no way to diagnose the issue, per se) prior to making the decision for a full re-build.