I am not experiencing the same issue, but...
when a program starts acting up as you have described, I delete the Preference file for the application.
Restart and it will build anew. You'll have to reset some of your settings perhaps because they will revert to the default settings. This usually fixes the problem.
Just noticed your mention that you re-installed. This may or may not have overwritten the preferences. I would toss them just the same and let the application rebuild.
I had trashed: User / Library / Prefernces / com.filemaker.client.advanced.plist, as a part of the re-install.
but forgot: User / Library / Caches / com.filemaker.client.advanced / Cache.db
before writing the above.
Before starting up today, both of these were trashed.
Made sure that I made no Drag & Drop mistakes and modified only a few fields (10 - 20) at a time. Most of this was deleting commented out code & reformating.
After clicking OK to exit Field Definitions, the Rebuilding dependincies and definition window close, depending on how many fields & their calc complexity, were worked on it would take from about a minute to over five minutes before I had access again.
I would say, the not resonding problem still exists.
David have your rebuilt your premissions?
Yes, all OS housekeeping routines have been performed.
I would add to my original Question,
This got started as aresult of trying to run a DDR which would hang about half way thru.
I know I have "Bad" scrpts that have been flagged for deletion, but those should show up on the report.
Thought I would check / correct Code before re running a fresh DDR.
Adding in the information about the DDR prompts me to suggest that there is something damaged in your file.
I had a similar situation with a file that would not produce a sound DDR. It appeared to, but when I tried importing into BaseElements, the DDR was not complete.
I was able to create a DDR with FMPv10 when FMPv11 was not. This helped me locate the corruption in a layout.
Have you tried creating a compressed copy of the file or a clone? That may give you a clue where the problem exists.
Which DDR? HTML or XML? If there's an issue with the file being corrupted, sometimes it can produce an invalid DDR, and this may cause issues with the HTML version. Try also with the XML and if it works successfully, and then you can try to check for validity ( let me know if you need help with that ).
Also if you wanted to send me a copy of the XML off list I can look at it for you and work out where the issue is coming from.
Most of the time I see this in layout issues, so it may just be a case of recreating some or all of a layout.
Michele & Nick
HTML DDR is the one that hangs.
I have taken up Nick's offer & sent him XML DDR back chanel.
As both of you pointed out layouts are suspect.
As I said to Nick;
I mention Layouts in that in the past I had found some Forms that had their "Parts" incorrectly set/ordered. I worked thru these and corrected them. I am not sure when or how these got messed up. You had also flagged layouts as a possible problem source.
I don't remember ever recovering these files. I run a daily/hourly compressed backup. If ever I have a problem I fall back to the backup.
It is my hope that it something small &/or maybe stupid that is easily fixed.
But who knows, most frustrating.
David sometimes you are talking about files and sometimes about the program. If it is the program which your reloaded, have you tried creating a totally new file and creating a DDR. What happens.
I apologize if I have intercepted the messages and missunderstand the problem.
No apologies necessary.
To answer your quandary, there are two Parts to the thread.
The original was the "FMA not responding" question.
The second is the response to Michele's comment regarding FM prefs.
I wrote a subsequent post in explanation and that I could not get an HTML DDR to run to completion, it would hang "not responding". This is why I was going through the File's field definitions thinking rightly or wrongly, that there maybe some bad code effecting the DDR run.
This DDR comment piqued Michele's and Nick's interest and thus their comments about layout corruption. To which I responded.
As your suggestion about running an HTML DDR on another file, it runs without problem, HTML DDR file size is 307 KB. Run as XML DDR, file size is 1.1 MB.
Actual file.fp7 size is 319 KB with 3 Tables.
As to the 3 file solution I am having the HTML DDR problem, it does do XML, with:
1. is a 1 Table, 1 Record file. XML DDR 258 KB.
2. Is a 2 Table, multiple records file. XML DDR 418 KB.
3. Is a 70 Table, multiple records file, w/ 1050 layouts. XML DDR 633.1 MB.
I have 402.25 GB available on my Hard Drive, so that should not be an issue.
There may well be some layout corruption as has been suggested and if so I hope it is minor.
But, I strongly do not think this has anything to do with working in Field Definitions and FMA "not responding".
As to the "not responding" problem, it still persists.
I can't get the DDR file to load in TextMate, it's just too big. It crashes the Java XML interpreter in Oxygen, and although BBEdit will open it, it seems to make it unresponsive.
I will have to attempt this on the command line, but it's been a while since I did this.
It might be worth trying to output the XML in two lots, one with everything except Layouts and one with Layouts only. 90% chance the issue is with the layouts somewhere, and confirming that and removing the rest of the code might help.
Per your request, If have uploaded two zips to the same location:
1. PIE_DDR_2011_11_17.zip with everything but layouts - prime file 82.3 MB
2. PIE_DDR_2011_11_17Layout.zip Layouts only - prime file 568.7 MB
Size must be what causes HTML DDR to choke.
If it would be of any help, I'ld be happy to send the files back channel as well.
I really appreciate your efforts on this.
1 of 1 people found this helpful
I don't think there's any corruption in the file, I think it's just too big for the XSLT parser ( which is the bit that converts to HTML for the report ) to handle. If you're wanting to try to analyse this file, I'd look at where you're using Images on layouts. The DDR outputs the image as a Base64 encoded text, so having lots of images can mean lots of data in the DDR. You can work around this completely by storing images inside container fields instead and that means it's not included in the DDR.
I couldn't find any issues with other aspects of the DDR either.
Best of luck.