Calculation Timing Problems?

[kennedy]

Not sure whether this belongs in ScriptMaker, Fields, Relationships, or here...

I have an Import File into which I imported the raw data, processed it, and then have a script that injects it into my real files. And then it detects errors (due to duplicate info having inconsistent data).

The data is being injected into two files: one the parent of the other.

So, my script first fills in the fields for the parent through its own relationship to the parent file that allows creation of related records. That works great.

Then it needs to create a child record. The relationship to the child file is based off a field that itself is computed from the child key field in the parent. Let me say that again... the parent has field "child" which is the matching field to the child file's ID. The Import file has field "child" that simply computes PARENT::child.

So, I tried having the relationship from the Import file to the child file allow creation of related records and simply set the fields. But I get an error message saying that you can't set those fields until the "child" field in the import field has a valid value. That makes perfect sense as FMP can't set it like it could set the parent pointer.

So, I set up a "New Child" script in the child file. Then in the import script, I set some globals with the values of the required fields and call the New Child script. That New Child script sets all the required fields AND sets the pointer in the parent properly. Presumably, then, the "child" calculation in the import file is now pointing at the new record. When the New Child script exits, it returns to the Import script which proceeds to set numerous other fields (the ones that aren't required). And this is where the problems are...

The first time I tried this, I ended up with two child records for each child record I should have had. One with the required fields and one with the non-required fields. I am assuming that the "child" calculation in the Import file does not recalculate when I use it during the script, and thus it was still blank... so it figured it needed to set the fields in a new related record... but then why did it allow it at all when it didn't allow it before. Its as if it sorta had a valid value... almost as if I am exercising an FMP bug.

So, then I realized that "allow creation of related records" probably should be off for the child relationship, so I unchecked it. Ran it again. This time I didn't get the duplicate records, but I did NOT get the non-required fields filled in. It ignored that part of the script without error even!

I am guessing there is some problem in the timing of when the "child" calculation gets recomputed, OR some problem in the timing of when the relationship to the child file gets re-evaluated based on that "child" calculation... or maybe some other weirdness.

Can anyone explain what's going on here???

Thanks.

[CobaltSky]

Hi Brian,

The issue hinges on the fact that, apparently, the relationship your script is using when it writes the non-required fields is not valid at the time when your script goes to set those fields.

I doubt that this is an FM bug, as I frequently create scripts which create a related record in one step and then send data to it in the next. In essence that's what you are trying to do but having problems with.

What is a little 'special' about your set-up is that you are using one relationship to create the record and another one to populate it subsequently. This begs the question as to whether there is a difference of any kind in the way the two relationships work.

The first thing I'd suggest you look at is whether the actual relationship the script is using for those non-required write steps is the correct one, is valid and is 'seeing' the previoiusly created record. A single redundant character (eg a space) or a mis-match of data types could be enough to trip it up and cause the script to fail. You might also like to confirm that the two relationships are both based on the same data type on either side.

I'd be pretty confident that there's a trouble spot in there somewhere, and once you can pinpoint it, the approach you're using will work.

[kennedy]

I'm fairly certain the relationship itself is not the problem as I simply re-run the script, taking advantage of the essentially identical update code and the same relationship to work around the problem and get those other fields filled in. Thus, although I have my data input, I am left wondering why it didn't work in one step. Hence, my question.

[kennedy]

AAARGHHH!

I continue to have great difficulty writing import scripts due to this calc timing problem...

In this new instantiation, the situation is this: In the import file, I compute "MemberKey" as the Parent key & the first name & the birthdate. In the Child record is a Calculation "ImportKey" computed the same. My MEMBER relationship matches those two. I have a bunch of fields computing off that relationship, and they are displaying valid data, so the relationship is working fine... in steady state.

I have a script that goes to each record in the import file and checks to see if there is a matching member... if so, it updates the info... if not, it creates one, and then updates the info. If I run the script when there is a match, it works fine. If I run the script when there is NOT a match, it creates one fine, but then fails to be able to update the newly created record because the MEMBER relationship is still invalid... it hasn't been updated yet. If I abort the script, the MEMBER relationship instantly updates, the screen is redrawn showing the fields properly, and when I re-run the script, it then finds that record and does the updates happily.

Sooo, is there some Script Step I can invoke that will cause the stupid calculations to fire and the stupid relationship to update... so that my script can call it after creation of the new record but before trying to set fields of that new record?:

[CobaltSky]

Relationships are driven by indexing, and the index is not updated until you exit the record.

Depending on how your scripts are constructed (in particular, the steps that create the new related record) it is just possible that the index has not yet been updated when the script comes to try to write to the related fields.

If so, including an Exit Record/Request step between creation of the record and the steps which try to write to it might have the desired effect.

HTH

[kennedy]

Thanks... that was it... I needed the Exit Record at the end of the external subscript in the child file that creates the new record.

I assumed the exit of the script, returning to a different file, would imply the exit of the record... now I know better.

Thanks.