Most hanging is usually from some type of corruption and FM recovery does not always detect the corruptions. If the hanging occurs on the same layout then rebuild that layout. Do not copy anything from the old layout because the corruption can be copied. Object as well as data can be corrupted. Best solution is to use a backup that does not have the corruption, but sometime that can be almost impossible. Going from 11 to 12 was a major change / upgrade. With a major upgrades it is usually better to rebuild your database to take advantage of the new features. FM may not have converted all the objects correctly when the conversion took place, which is another reason to rebuild.
As I stated, I used a clean copy ie never crashed to import the data. The converted files were clean (never crashed), we keep clones of every version released.
The recovered files were only used to export the data (we use the separated data model - data and layouts are in separate files). The data was imported into a clean file.
When hosted in a different environment, the "not responding" does not occur. If it was a corruption in the files, it should happen in all environments.
Generally, when an object or script is corrupted, it should happen every time you click on the corrupted item.
This is more tied to an individual record, however once the record is corrupted it will always hang at that record. All other record perform as expected. Today, I viewed a particular record , then someone else tried to view the same record and it hung. Now I can't view that record.
This solution is a couple of thousand hours, rebuilding from scratch is not an option. We rebuild modules as budget permits.
It is not uncommon for corruption to only show up after upgrading to a new version of FM. There were several similar type problems reported on the forum when FMP12 first came out related to files that had been converted from fp7 to fmp12. The conversion process was / is not perfect. It was a major upgrade.
You would think it would happen every time when the item is clicked, but it does not happen that way in the real world. It could be the order things are clicked, that makes the object perform differently, which is one of the reason it can be to track down.
My guess is that something did not convert correctly. I would strongly recommend a rebuild. Again, it was a major upgrade from fp7 to fmp12 files.
I hear what you are saying but why does it only exhibits this in this one environment? Why aren't the other locations showing the same kind of behavior?
You are guessing that is the only difference. Have you tested on multiple systems that are identical? We can speculate and guess what the issue is and waste several hours looking for the problem or find a way to get a working solution. I have seen several post in the pass with similar issues and it was in most cases a issue with the conversion from fp7 to fmp12 or a corrupt object on the layouts.
I'm not disputing your conclusion but I want to learn when I encounter a new situation.
When the exact same program works properly in 3 other locations with the only difference being the data and system configuration, I tend to focus on what is different for the source of the problem. Even if I rebuild the solution from the ground up, if the operating environment (or data) is the problem, it will still fail , and I will still have spent the $$$$ without a working solution.
As I mentioned this is a large solution (75 tables, 1,399 relationships, 600+ layouts etc) and even if we were to just rebuild the affected layouts it would be a minimum of $20,000. Since you are fairly certain that there was corruption during conversion, is rebuilding the affected layouts sufficient or should all layouts be rebuilt? Are they the only items that would get corrupted during a conversion? Can I count on the relationships to be unaffected? What about the field definitions, are they unaffected as well? What about the scripts? A complete rebuild of exactly the same solution would be close to the 6 figures range. This is one of the greatest weaknesses of FileMaker that most IT departments like to focus on when evaluating it for acceptance. A solution can't be rebuilt with automation. It has to be all hand built. I am not aware of any tools that will do this (there was FMRobot from a long time ago that did some of the work), is there a similar tool today?
It's not a matter of disputing my word or statements. That is not my point. Issue like this can be very difficult to track down and even more different when I can't test the database myself. Sometime you can waste more money and time trying to figure out the problem, when you could have just rebuild the database / layout in the first place. Spend $20,000 to figure out that you need to spend another $20,000 to rebuild.
If it is a large database then I would only rebuild the part that I'm having issues with. I would also create a smaller test database to see if I got the same results in the new smaller test database.
Make plenty of backups.
It's easier to rebuild a solution in FM than it is in any other solution. None are automated. I've program in several different database and computer languages, rebuilds are sometime required to stay current with new technology. Going from fm9 to fm10 to fm11 or fm12 to fm13 to fm14 I would not state that a rebuild would be necessary but from fm11 to any of the newer version would almost be necessary. Again I would just start with rebuilding the layouts I'm having issues.
Maybe something happen to the file on this system, so have you tried a backup copy of the database from one of the working location on this system that you are having the issues? Test with the data from the working version, if no issue make another clone without the data then import your data into this cloned database and retest. If issue still occur then rebuild the layout with the issue.
I understand it can be very expensive to rebuild, but how much money are you losing with the system not working and how much money will you lose if the database completely crashes.