Script Will Not Run All Steps

[Aman]

Hello Everyone,

I am trying to clean up a database I inherited and am starting with some of the scripts. I'm currently creating some reusable scripts. They seem to be working until one of the finds in the reusable script returns nothing. The script appears to finish cleanly, except that it will not set fields.

The "Run" script fails when the script reaches the "Corporate" section. This correctly returns "0¶0¶0¶0" because there are no matching records. However, the "Set Field" script steps that follow never seem to execute.

I can add other steps that will execute properly, but "Set Field" steps will not.

When the "Run" script reaches the "Customer Programs" section, the script correctly returns "34¶0¶17¶0", but once again the "Set Field" steps don't appear to execute.

When I look at it with the Data Viewer,

"Get (ScriptResult)"

"GetValue ( Get ( ScriptResult ) ; 1 )",

"GetValue ( Get ( ScriptResult ) ; 2 )",

"GetValue ( Get ( ScriptResult ) ; 3 )", and

"GetValue ( Get ( ScriptResult ) ; 4 )"

all show the correct data. So why won't the fields accept the data?

I assume there is something I am doing wrong, but I cannot for the life of me figure it out. I've tried using global fields instead of the variables and that doesn't act any differently.

Okay, that's all for now. Any help will be greatly appreciated.

Thank you,

Aman

Team_Project_Breakout_-_Run.pdf

Team_Project_Breakout.pdf

Edited January 24, 2007 by Guest
Formatting

[dazlunn]

What kind of fields are the 'open' & 'closed' fields that the script is trying to set?

It looks to me like it's a summary or sum() field that calcs: (no. records opened) vs. (no. closed)

If so, you can't use setfield on this type of field. When you say you tried global fields also, did you mean you just changed the calc fields to global storage? Or are the field types text, number etc??

Edited January 23, 2007 by Guest

[Aman]

What kind of fields are the 'open' & 'closed' fields that the script is trying to set?

It looks to me like it's a summary or sum() field that calcs: (no. records opened) vs. (no. closed)

They are simple text fields that are being stored in another table. That table only has 1 record.

When you say you tried global fields also, did you mean you just changed the calc fields to global storage? Or are the field types text, number etc??

I meant that I set the script variables to be local global fields.

The strange thing, is that it works fine if use 7 different scripts that are hard coded instead of using variables. Of course in that instance I am using "Set Field" after each part of the script, rather than adding to local variable.

Btw, this is a shared database hosted on FMS 8 Advanced. I have tried it on a local copy and end up with the same situation.

Is there another way that I should be doing this? The fields that I need to set don't have to be in another table since they do not need to be stored. They could be local globals, but that is a project for another day.

Thanks,

-Aman

[dazlunn]

Quote: I meant that I set the script variables to be local global fields.

Can you explain this a bit clearer, I don't follow...?

[Aman]

Quote: I meant that I set the script variables to be local global fields.

Can you explain this a bit clearer, I don't follow...?

Sorry, what I meant was...to test whether or not my flaw was in using script variables improperly, I temporarily substituted a couple of global text fields for storage instead of the script variables. It didn't affect the outcome in any way.

-Aman

[dazlunn]

On your second script I notice that you are using setfield in conjunction with find mode... Setfield is used normally to change the contents of a field and not for find criteria.

Try using Insert Calculated Result instead and see if that works...

[Ender]

On your second script I notice that you are using setfield in conjunction with find mode... Setfield is used normally to change the contents of a field and not for find criteria.

Try using Insert Calculated Result instead and see if that works...

Actually Set Field[] works fine for setting Find criteria and is preferable since it doesn't require the field to be present on the layout.

I can't tell what's wrong here. If the field types of those Preferences fields for those categories are the correct type, then it looks like it should work.

Since the "End of Year Comparison - Team Project Breakout" script is returning the correct results, the problem would have to be in the "End of Year Comparison - Team Project Breakout - Run" script, or with the destination field types.

[Aman]

Well in my haste to implement dazlunn's suggestion, I didn't set a calculation properly and realized that everything works fine when the final Get(FoundCount) in my first script doesn't return a "0".

I added a "Show All Records" script step right before the Exit Script[] and everything works like it should.

So now my question is, why is that the case? Is it actually because of the "0", does it have to do with being in a state of error (I am doing an Error Capture[On] in the grandparent script), or is it something else entirely???

Any ideas?

Thanks for all the help.

-Aman

[dazlunn]

Yes, true - my articulation was not very clear...

I should have said that it's not what 'I' normally use, have had querky experiences previously and try to avoid this method...

I was struggling to see where the scripts were falling down, other than field types...

Sorry!

[Ender]

Ah, now it makes sense. When the found set is empty, there's no parent to establish a relationship to the Preferences table. As you have discovered, reestablishing a found set fixes this.

Another way that may work is to have the Preferences fields be globally stored. The side effect from this would be that those fields would be session-specific and changes made would not be visible to other users in a multi-user environment. This could be good or bad depending on how you use the data accumulated in the Preferences table. If you like giving each user their own workspace to run individualized reports, then this would be good. but if you have one person run this report for the purpose of making the summary data available to all users, then the globals wouldn't work for you.

[Ender]

Hi dazlunn,

I'm not sure what kind of quirky experiences you have had, but from my experience Insert Calculated Result[] is less reliable because of the requirement that the field be present on the layout. It makes the scripting more complicated as you have to navigate to a developer layout every time you're doing such operations, and makes layout editing prone to messing up any number of scripts.

I have abandoned Insert Calculated Result[] completely from my development.

[Aman]

Ah, now it makes sense. When the found set is empty, there's no parent to establish a relationship to the Preferences table. As you have discovered, reestablishing a found set fixes this.

Thanks, it's good to know the reason behind this.

Another way that may work is to have the Preferences fields be globally stored. The side effect from this would be that those fields would be session-specific and changes made would not be visible to other users in a multi-user environment. This could be good or bad depending on how you use the data accumulated in the Preferences table. If you like giving each user their own workspace to run individualized reports, then this would be good. but if you have one person run this report for the purpose of making the summary data available to all users, then the globals wouldn't work for you.

This is exactly what I am planning to do. Everyone that runs the reports adds individual requests in a previous script, so there is no reason to keep these fields in a separate table. In fact, not having these be session specific has caused a couple of issues in the past.

Thanks for your help,

-Aman

[dazlunn]

Ender,

Only noticed your reply last night whilst scanning thru my old posts and I hadn't replied so...

Your reply made me question myself, so I tried to track back to where my 'Setfield in Find Mode-phobia' came from and I just can't determine it, only thing I can think of is that I did use it a few times way-way back with scripted date finds and had a few problems.

But I just tried it in many instances today and all work fine!! AAaahhh... and I'm really such a tenacious so and so! and that is just sooooo basic too...

Oh man, my pride is really hurting now.. woe woe woe.... need a pride-repair-pill !!!!!!

I spend half my time telling people they are stuck in a paradigm.. and I was in one myself!!