Jump to content
Server Maintenance This Week. ×

Insert caluated result places data in wrong field


This topic is 5392 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Since upgrading to V10 I have noticed a few odd occurrences when using "insert calculated resulted" script step. It seems to place the data in the wrong field. It had all been working fine in 9 but since the upgrade it has been problematic.

It doesn't happen all the time, it seems to vary from script to script and some can be solved by running the step while in a different layout and switching back. All very odd.

Any ideas?

Thanks

Rufus

Link to comment
Share on other sites

I have to say, I've never used Insert Calc Result. I'd look for a context issue (if switching layouts helps, perhaps you're actually switching to the correct context).

Why not change to Set Field?

Link to comment
Share on other sites

Beyond that we now are allowed indirection with fm10, is Set Field[ dangerous in a similar way, if you avoid writing a fields name in the reciever part. Then will it follow the flow or tab-order in the layout.

But everything based on the order in the layout are bound to give errors if something suddenly changes position. I too haver never really used Insert Calculated result ... it must be kept there as legacy compatibility from fm6 where it had it's use when writing a date-range in date field to circumvent the bleeping when "..." was attempted, via Set Field[

But at this day and age has it no use anymore, except in either poorly designed solutions or migrated solutions from pre fm7 ... where it then eagerly awaits being turned to Set Field[

--sd

Link to comment
Share on other sites

I find insert calculated result is a very useful script step and I've never seen it fail before.

I can't see that this can be context or position related as the script step specifies the field to insert the data into. It's just that for some reason, it sometimes gets it wrong.

Further to this, i've just noticed that it has started happening ( on occasion ) in V9 as well. Could the database have become corrupted? If that is the case, how would I fixed. Clone and re-populate?

Thanks

Link to comment
Share on other sites

Check the tab-order, perhaps it's where weakest spot is in the scenario.

If a field is deleted and then added again later, could it explain the entire issue. "Insert" "copy" and "Paste" strong dependency on a specific layout is pretty risky in my opinion - it's much more my liking to make wrappers, such as:

http://web.mac.com/zueiv/iWeb/FileMaker/Script%20Killing%20Techniques/AFA363C6-2D85-4C6D-82E2-273F3722A69E.html

Because a uniform method exists for the entire solution universally.

--sd

Link to comment
Share on other sites

  • 6 months later...

Hello,

I have the same problem Rufus mentioned.

This script below doesn't do what it's expected to do. It tries to insert the value of the variable into a different (incorrect) field (which FYI is from a different related TO). I can't see any logic as to why that field is chosen. When I deleted the incorrect field, then another incorrect field was chosen. When I deleted THAT field, then everything worked properly.

This used to work in FM 9. I recently switched from FM 9 to FM 10 (both for client and server, though not at the same time.) If I now open the file directly in FM9 (i.e., not served/shared), it still has the problem.


# Go to Layout [ “Main” (END__) ]

# Set Variable [ $EndowmentKey; Value:Get( ScriptParameter ) ]

# If [ IsEmpty ( $EndowmentKey ) ]

# Else

# Enter Find Mode [ ]

# Insert Calculated Result [ END__:e_endowment_pk; $EndowmentKey ] [ Select ]

# Perform Find [ ]

# End If

Thanks,

Marek

Link to comment
Share on other sites

This works now.

I replaced the script step "Insert Calculated Result" with "Set Field" (as suggested by bcooney, 01/09/09 07:36 AM)

I had been under the impression that "Set Field" didn't work with calculations (more specifically with variables). Maybe it didn't use calculations in earlier versions, or maybe my impression was wrong.

Marek

Link to comment
Share on other sites

This topic is 5392 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.