Go to Related Record issue?

[Tompa79]

Hi!

I have a small problem or rather annoyance.

I have a solution with multiple files and when using Go to related record script step with table from another file scriptmaker displays the wrong or unknown layout after closing the gtrr dialog - like this:

GTRRBug?

The script in itself performs as it should. What I am worried about is that this is a symptom of another more serious problem.

Anyone else ran into this? Should I worry?

(BTW: Recover does not help, save as compressed does not help)

Thanks!

/Tomas

[Fenton]

Well known problem, has been there for quite a while, far too long. It could be called a bug, except it is just a display thing; if you open the Go To Related Record dialog you see that it does know what the right one is. What I do is put a comment below with the name of the correct relationship, just so I don't freak out. So don't worry, not about that anyway.

Do NOT Recover the file! That is not the appropriate thing to do. FileMaker should warn people better, but Recover is not meant to be used on files you will continue using. It is meant to aggressively stablize the file so that you can get the data out; it can remove bits of the structure if it considers them suspect. In other words, it's the worst thing you can do if you suspect structural problems on a file you have no clean backup of; though you do, don't you -?

The File Maintenance steps in FileMaker Pro Advanced are also not recommended. Save a Copy as Compacted (compressed) is really the only safe thing to do. I don't know that it can really "fix" structural problems, but it can (hopefully) straighten out indexes, which is critical.

If I were you I would go back to a backup copy of your file if at all possible. Import more recent data. Redo structural additions. If not, you're probably OK (but not "good"), as your file was likely not damaged at all to start with. But don't do it again :-! And backup your files more often -!

[Tompa79]

Well thats a relief. : That it's just a display bug.

The recover action I did was not on my actual working file, but just a recent backup file. I am careful, and I know the implications on recovering - it's just a last resort kind of thing. From what I get - to study a recovered file of a solution might be good use of time. A recovered solution might display erroneous data/things with weird symbols - theese kind of errors might not be (but often are) discovered in a consistency check from what I heard.

And about backup - I do it on hourly basis. Could do it more often perhaps, but it suffices for my purposes I think.

Many thanks for your answer! I agree - Recover action should not be used casually...

[Vaughan]

"A recovered solution might display erroneous data/things with weird symbols..."

Not sure what you mean.

A recovered file might have bits of script or layout missing which would be extremely time consuming to find in a large and complex solution.

[Tompa79]

What I am saying is actually what you said - things which are not as they should be. Things that the consistency check for some reason missed.

You can discover errors in your file earlier if you do this check regulary. You might see errors in your files that otherwise would not be found until your end users start to use that particular part of the file. And yes it's probably time consuming...

The popular "go back to your latest safe backup" might not help if the error was created way back in development.

Not sure if I make myself clear, maybe it's nothing, but I have collegues who has ran into theese kind of trouble. (rare, but has happened)