Is there any way you can try and open it on another layout that does not have that calc field on it or better yet an entirely different table.?
No, sorry. I've also tried sending an event to the file, but the moment it opens it is unresponsive to anything I try.
From what I understand, it computes the variables first before even computing any scripts, so sending an event to it would have little to no effect.
Where exactly is the offending calculation is it a variable in a script or is it a field in a particular table.
Do you have access to FM10 Advanced
Thank you for your kind interest in helping me.
Unfortunately, the exact formula I do not remember, as I cannot access it. However, what I can tell you is that the DB is relational. But the field that has caused me this problem is not accessed by the other files, or, in fact, any scripts. It is isolated and in a table. I was just inserting an amortization formula for a billing section of the DB.
That said, the variable is a repeating field. The formula inserts data from another repeating field of a prior index (different the one doing the calculations) using the [ ] notation (and not the repeating field function). For index = 1, it uses an altogether different reference.
When I saved the formula there was notice of it being recursive. Prior versions of the formula worked fine until I added the index part. But because I cannot access the code anymore, I do not exactly remember what the code was.
I am using FM 7 Pro. I can get FM 10 Advanced as a demo and try it there. But the question is, why? Can it do something in this instance that version 7 can't? If so, it'd be worth the upgrade, at least to save many hours of lost work.
As far as I know, advanced versions of filemaker are not available for trial download. If you had a copy of advanced, you could enable the script debugger, then open the file. If this calculation were part of a script that runs automatically when the file opens, the debugger would halt the script on the first step and you could then cancel the script and now you have the file open in a state where you can fix it.
I could be wrong but this sounds like you have a calculation field with a recursive calculation on the layout that is current when the file first opens. In windows systems, you can sometimes halt these calculations by pressing the escape key. Option period does the same for macs if I remember correctly.
You might also be able to create a new filemaker file and run a script from it that performs a script in the other file. Try to run a script that switches to a layout that does not contain this field or that omits all records so that you have a found set of zero records. Either option depends on whether you have such a script already created in your file.
Yes, you do remember correctly. This works beautifully in a script, but does nothing for calculations. I also tried loading the file externally, and sending an event to the file with a 'command-period' command. It did nothing, as expected.
Recursive formulas usually involve referencing the same field (via another field) to define its value, and FileMaker is built to warn against such occurrences. In this case, the reference was only in an if-then statement, and its value was not used to define the current value. It was only used in determining how the current value was defined. So it shouldn't have been a recursive calculation. That there were no errors upon saving the formula should've proved it, except for the never ending spinning circle that followed on my Mac (OS X Tiger) immediately afterwards.
That it is a recursive calculation is correct. But how it became one, I do not understand, given the description above.
In regards to layouts, the thing is that the file actually opens in a layout that does not contain any reference to the variable. This can only imply that FM 7 Pro computes all variables, even if they're not being used in a layout. I wonder if other versions differ on this. However, deleting all records... that I haven't tried. I can always import the records again later. This script does not exist, but I should be able to send an event to it and access the built in 'delete all records' function of FM.
I will try this and keep you posted on my success. I fear, though, that any internal and external scripts are only processed once the internal variables are processed. This would imply it will never get to the event that was sent.
Depending on the size of your solution it may be possible to import the tables into a new file when you get to the one with the issue you can then edit the calculation to prevent the problem (or the import may break it enough if its references are all wrong)
Just a thought.
I will try the importing, though there are a lot of tables. We shall see what happens.
I've tried the remote event without success, as anticipated.
I am about to give up, and call it an FM bug. Never came across anything like this before, and I've been programming FM since version 3.
Thanks again for the support. I will keep you posted on the results.
The results are that nothing can override FM and there is no way of stopping the recursion. None of the suggestions worked.
In the end, I had to retrace my steps and develop the file as before. Fortunately it didn't take so long the second time.
Then I came upon the same problem again.
Here is the culprit:
If ( $$_index = 1 ; $$_invoice_start ; $$_due[$$_index - 1] )
A simple formula, but as soon as $$_invoice_start is given a value, the recursion begins. Keep in mind that $$_due is derived from the previous repetition of the repetition field doing the calculation, and that the result of the calculation does not define earlier repetitions. It's something that would make perfectly sense in a spreadsheet. Oh, $$_index is simply the repetition number doing the calculation. I put it in a variable.
Hmm, I think here is where the error lies. It must be that FM calculates all repetitions simultaneously, and not in series, one repetition after the other, like I presumed. The Latter would make far more sense. I could not find any documentation on this.
What's the name of this field and what settings have you selected for it? I don't see any recursion here.
How do you "assign a value to $$_index ?
I may be missing something, but $$_due[$$_index - 1] makes no sense to me and I'm suprised it doesn't trigger an error message when I paste this in to a calculation field's specify calculation dialog and click OK.
To refer to a repetition in filemaker, you normally use GetRepetition to extract a specified repetition as Arrays don't exist in Filemaker.
In my initial test I defined a calculation field and pasted your expression into it. I then used a script to assign 1 to $$_index and, as expected, nothing happened and no value was displayed in the calculation field. Obviously, I'm doing something different than you.
Yes, no recursion at all. You're correct. I called it that at the time because I didn't have access to the code in error, and had no idea what else it could be. After doing the simple test below, I feel no different now than I did before.
To answer your question, $$_index is set by the repetition field doing the calculations. If field 10 of a repetition is doing the calculations, index would be 10. The exact formula is:
Get ( CalculationRepetitionNumber )
$$_due[$$_index - 1] is the same as GetRepetition($$_due ; SS_index -1). Both formulas work great as long at they have no connection to a previous repetition of the same field. That field I called $$_invoice.
I just did a simple test, and it seems to work fine if the indexing is off. For the first repetition I gave a = 0, b = a + 20. For all other repetitions, a = b[$$_Index -1]. index is defined as above.
It appears my problem lies somewhere else.