Need Help With Apparent FM Corruption Issue

Questions
1

My client has a large FM application.

Trying to search her scripts with Developer Assistant hangs at about the 90% mark.. I don't believe this is a DA problem, however.

Here's what I've tried:

I ran "Recover" on the FM File, but that didn't find anything and DA still hangs on search.

I deleted all the scripts except for the 1 script that hung DA. I then ran DA and it hung again with just one script. The moment I started the search I got the FileMaker busy cursor/icon followed by the beachball.

I also tried to copy and paste this "problem" script into a new script and deleted the old one (now only a single script in the scripts window) and DA still hung trying to search it.

Also tried a clone. No data. Did not work either.

/--------

But when I copied this script to a brand new FM File, DA had no problems and searched the script easily.

The DA developer has been amazing trying to help me figure this out, but it seems there is some kind of corruption in the client's FM application that FileMaker cannot fix and DA can't be expected to work around.

I doubt the client would take weeks or months to totally rebuild and re-import a huge, huge project.

I'm therefore wondering if anyone has suggestions on what I could try. Without a tool like DA where you can search by RegEx, go live to your scripts, etc., it's very difficult to keep up a huge application.

Plus, and possibly even more important, if the client's application is corrupted, what could happen next?

Thanks in advance for suggestions,

2

How about deleting or rebuilding the script or finding the script step that hangs DA?

1 Like
3

As I mentioned above (see the italicized text), I found the script and reentered it by hand. That did work, yes, but it's not a good solution to ask a client to do if an alternative exists.

I was also wondering if anyone else has ever seen anything like this issue.

Thanks

4

My bad! I misunderstood what you meant by "copied this script".

In answer to your question, I have seen something like this in scripts and in layouts. I usually solve these issues without resorting to a full rebuild by isolating a script step or a script and rebuilding only that script step or script.

You may not like it but, sometimes, rebuilding a portion of the solution is the best solution, as in the most expedient, inexpensive or practical at the time. A restore is not the recommended approach to fix this type of issue anyways. The recommendation is to use a restore to get the data from a restored file and then migrate this data to a known good copy of the solution.

Hope this helps!

1 Like
5

To me this does sound more like an issue with the developer assistant third party tool than FileMaker itself. Sounds like it is struggling with something in the script. Copying it to another file may only fix the issue because the underlying issue in the script is not present after copy/pasting to a blank file.

Could be something that script is referencing in an external file perhaps, or an unsupported new script step etc.

Either way if the script can be opened, viewed and executed without issue in FileMaker, it's not corrupt.

You might have more luck contacting the developer of the tool directly about this issue as they may be able to guide you on how to submit to them trace logs and crash reports to help identify the exact issue, and at the very least rule it out being an issue with the developer assistant tool.

6

We can't know what the cause of the issue was but when you are experiencing odd problems, recreating objects can be the only way to overcome the problem.

I once had a layout showing problems. We removed every single object. It was the layout itself that was buggy. When we removed the layout we had to re-code dozens of scripts because the navigation was hard coded to the layout ID :laughing:

1 Like
7

Aaaaaah… no! Corruption is not always apparent. Like a cancer, corruption results in unexpected code execution. It can be benign or malignant. Malignant corruption may not even show a problem at first, in which case the repeated execution of corrupt code eventually results in visible problems.

8

Thanks

9

Yes, I cloned the application and removed all but the script that was causing the problem. DA still hangs. If I type the script manually into a new script, DA is fine.

I'm working with the DA developer who is really trying to help me figure this out with logging versions of DA and I'll report any progress or fixes.

Thank you, Malcolm.

10

Developer Assistant software issue is fixed!

Turns out to have been an issue with client FM application where DA was trying to look up table names to know how to report an issue, but because of missing fields in FM application, it was taking too long.

Issue: (FileMaker) SQL lookups were very slow on this system.

In any case, the Developer Assistant developer was incredible. Amazing support.

This issue is fixed!

3 Likes
11

Nice, so not corruption in your file which is good :slight_smile:

1 Like
12

Well, yes and no, depending how you look at it. Not outright corruption, yes, but there were simply too many "broken references" which FileMaker ignores, but DA doesn't (and can't so it can properly classify things it finds). And FileMaker continues to be pig-slow with SQL (nothing new here) and couldn't keep up.

13

FileMaker is NOT an SQL database. Everything under the hood is Draco. The most that we can expect is that it will be SQL compliant. Yes, Claris is providing "SQL-like" commands but these commands are interpreted and performed in Draco.

You cannot seriously be blaming FileMaker for missing field references.

Missing references occur when fields, scripts or custom functions (which are referenced in other scripts, fields, custom functions or layout objects,) are deleted. The developer who pressed the delete button could have run a DDR before deleting, and searched for references to the object. It's as simple as opening the DDR in a good text editor and doing a search. Whoever decided to remove the referenced objects did so without regard for the impact on the system.

The fact that Developer Assistant was not able to handle missing references is odd, as they occur very frequently in FileMaker databases.

1 Like
14

FileMaker tries to have it both ways: They offer SQL in many ways, but when performance isn't there, you hear "FileMaker isn't a SQL Database!". LOL.

No, I was not blaming DA for client-caused missing references. Not sure how you got that. What I was saying is that since DA must do lookups on these things, it had problems with the pig-slow SQL in FileMaker and was basically unusable on this application.

Working with the DA developer for weeks with multiple debugging/logging versions of DA, we finally figured out what the problem was. Had I had the source code to DA (C++, presumably), I could have figured it out on my own.

Thanks.

15

Not a perfect solution, but I've had luck uploading the XML Database Design Report to ChatGPT and then asking it to find things. It's an 80% solution (it makes up things sometimes, and misses things other times), so it isn't a replacement for DA, but it's sometimes faster and easier...

2 Likes
16

Thanks!