Circular Definition/Is it Possible

[RPCia]

Has anyone ever experienced this/Is it possible?

FMP 6 Dev, Win XP Pro

I have 6 files that were developed before my time and were all based on an original master file. ( they have the same basic structure/purpose)

I am being asked to make some major changes to 2 of these files I had no problems with the first but when I go to make the changes to the second I got 95% done and then went to update a field definition and the file crashed.

I have spent close to 20 hours on this trying to determine why it is happening. I have a couple of theories and questions for anyone who has had more experience with FMP

Theory/Questions

1) The file is truly corrupt and I should just give up and rebuild the solution, however that will probably take 40 hours just to rebuild this one file, and probably another 40 to find all the scripts and file references that the last 3-4 developers have created in the 100+ files that referenced this file. (without any documentation)

2) Is it possible that I have unknowingly caused a circular definition and FMP is not catching it, hence when it trys to rebuild the stored calcs it is causing an error to occur?

3) Why is it that only with this file when I make any field definition changes even small ones. I get a window before the updating fields box. That says Title: Field Definitions Dialog: Rebuilding Dependencies.

4) It is at this same point that the file crashes and I get the file crash boxTitle: Error in file... Dialog: The file is damage click Continue to continue....

It only crashes when I insert my case statement that tests for the lowest value and chooses a machine to run the job on.

I have been able to alter the field definition just not able to insert my case statement.

I have tested my case statement in both the current file with a new field and in a completely seperate file and it works fine.

Thanks for any help

[BobWeaver]

The file is probably corrupt. But, here is something you may want to check. For each calculated field, check its formula. One of them may have gotten corrupted, but the compiled version may still be okay (Filemaker pseudo-compiles field definitions from the displayed version in the editing session), which explains why the file works until you edit the field definitions. Open each formula definition and then close it. This will give FM's syntax checker a chance to check each definition, and possibly find something it overlooks when it rebuilds its dependencies.

[RPCia]

Thanks for the suggestion. So it seems you agree then that the likely hood of their being an unknown circular definition is remote and that it is likely the file itself?

I can go back and use a backup from a year ago if I have to. But I am just worried that I will spend the 10 hours setting up the file and get to the last part and this will happen again.

I guess this is also assuming the backup file has not been corrupted. The field that is causing problems is referenced by about 50 other fields and up until now has not needed changing since the file was first developed.

These files are over 6 years old and when I started 2 years ago, the computer that was hosting them did not even have a battery backup, and our building gets power surges all the time.

Thanks again

[RPCia]

I just had another thought, expanding on your suggestion,

• Create another field with the calc I need
  
• Then replace all the occurences of the troubbled field with the new one
  

Maybe just maybe!

[BobWeaver]

Maybe, but I'm thinking that the corrupt definition is not the one you are working on. That's because the one you edit gets syntax checked and updated. Meanwhile there may be a corrupt one lurking in there somewhere, and when Filemaker goes to rebuild its dependencies, it looks at all the other definitions to see what fields they reference, and when it finds the corrupt one, it pukes (that's a technical term). That's why I suggested that you look at each definition and if one of them looks garbled, you may be able to fix it.

In any event, I really wouldn't trust a file that is known to be corrupt even if you do get it to work. I would go back to a good backup if there is one, and work with it.

Edited October 4, 2006 by Guest

[RPCia]

I see your point.

I did try to create a new field and insert it, but that did not work.

I also printed the field defintions to a pdf and looked through all of them they seem to be ok visually.

I will either use a backup or start from scratch, depending on how brave I feel at the time.

I have spent to much time trying to fix this already.

Thank you for your suggestions.

[RPCia]

OK, I rebuilt the entire file 1744 fields.

I am having problems importing data. When I import the data some of the stored calculations do not get updated.

Is there a work around for this, or am I doing something wrong?

[BobWeaver]

OK, I rebuilt the entire file 1744 fields...

Whew! You have more patience than I do.

The only problem that I can think of would be stored calculations that reference Status functions. But this would have been a problem in the original file as well. Can you give an example of one of the calculated fields?

[RPCia]

Whew! You have more patience than I do.

ya, well I took it as I had no other choice.

I'd say 70% of the fields are calculations, so I used a pdf file to copy and paste the calcs, all and all it probably took me 16 hours

totalNumColors(c,n eval always) = blkFrnt + PMSFront + StdFront

all three fields are number fields

I import the sample data 50 records and the calc does not evaluate.

StdFront for example has a 1 in it, if I set it to 1 again then the calculation will return 1 until then it is empty

[RPCia]

also any new records added seem to work fine

Another example fieldName(c,n,eval always)= 1

just the number 1 for a constant and it is empty when I import data but if I create a new record its value is 1

[RPCia]

I had another thought.

Someone, correct me if I am wrong but I seem to recall reading somewhere that the conversion process from 6 to 8 may help take out some of these issues.

I may try to convert all 150 files to v 8.5, I had been holding off because I really wanted to develop a new system before doing the conversion since the current schema is in no shape/form properly structured. I did not want to deliver a version 8 system that was the same as the current one. I am a little worried they will get comfortable with it and not allow me to change the system.

However if it will solve this problem I can convert the files and then slowly rebuild them 1 by 1.

Any thoughts?

[BobWeaver]

According to some of the posts I've read, the conversion to 8 can also cause more things to break. So, you are taking your chances.

A quick fix of your existing file might be to do a Replace on one of the referenced fields, replacing its value with itself. This would then force a recalculation of the calculated fields.