Script Parameter; Missing Table ??

[Veronica]

I have a situation where I pass script parameters to a local variable to run subscripts depending upon the user's preference for output type. This technique works fine in one database but won't work in the other.

I have "Report Selector" layouts in both databases. Each report selector layout and the output layout are based on the same table respectively. There is a global field called [gOutput_Choices] in each table that displays as a radio button value list, (View, Print, PDF, etc.) Whichever option is selected by the user is passed as a script parameter to the set variable, ($Print_Choices), script step which will cause the appropriate subscript to execute.

Using the Data viewer in the script debugging process, it appears that the "Table is missing" according to the data viewer. I have re-constructed the Specify Scriptparameter several times from scratch using the Case statement, (which works OK in the other database.) I can't figure out what's wrong.

I don't know what I could be missing. Does anyone have any ideas? Here is my script:

Go to Layout["SchoolAttendanceUnified" (Attendance_TO)]

Print Setup [Orientation: Landscape; Paper size: 8.5" x 11"]

Show all records

Enter Browse Mode

Perform Find{Specified Find Requests: Find Records; Criteria: Attendance_TO::cEnrolledFlag_1: "X"]

[Restore]

Sort Records [specified Sort Order: (Several fields; Sort criteria works fine)]

[Restore; No Dialog]

Set Variable [$$Print_Choice; Value:Get ( Scriptparameter)]

If [$$Print_Choice = "View"]

Perform Script ["View Script"]

Else If [$$Print_Choice = "Print"]

Perform Script ["Print Script"]

Else IF [$$Print_Choice = "PDF"]

Perform Script ["PDF Script"]

Else IF [$$Print_Choice = "Excel"]

Perform Script ["Excel Script"]

End If

// Perform Script ["Output Choices"] (Note: I thought: "Why not put all these together in one subscript for use in multiple sripts.")

Go to Layout ["Report Selector" (Attendance_TO)]

Enter Browse Mode

Halt Script

I would love any other comments on this approach. Thank you all in advance.

[Søren Dyhr]

If you go to a layout which isn't relational tied to the fields you're referencing is the dataviewer urged to make complaints, only global fields can be accessed sans ties.

My guess is that although the data belongs to correct table, is the layout showing a wrong TO's data.

What I beyond that really can get, is why you turn into browse while already being in browsemode:

Show all records

Enter Browse Mode

Perform Find{Specified Find Requests: Find Records; Criteria: Attendance_TO::cEnrolledF lag_1: "X"]

[Restore]

Stored request needs not be turned into different modes, like you attempt to in the second line.

another thing is why you when already having the choise in global fields turns them into global variables as well, which honestly doesn't seem to survive way into the subscripts ...we have an extpression for such "...crossing the creek to get water"

--sd

[Veronica]

Hi Soren,

The report I'm trying to produce and the Report Selector layout are both in the Attendance_TO. (I probably don't understand how to use the data viewer very well and may have misunderstood what I thought it was telling me; "Missing Table".)

I also thought that using Script Parameters in this case is really un-necessary overhead. But I tried the method where I use the global field as the source for my global variable and it didn't work either. So I went back to the method that worked in the other database.

About the stored find request; Are you saying that the "Restore" option is not necessary?

Thank You.

[JesseSFR]

It is definitely hard to see any error in your code. Could you provide the statement that you use to construct the script parameter? If your data viewer says missing table that is definitely a lite weird because global fields should show up no matter what table occurrence you are on even if they are not related to your current TO. You might want to ensure that your field is indeed global.

As far as this code goes I would like to expand on Orens point about the globals. The variable you created, $$Print_Choices, is indeed a global variable. I would change this to a local variable which is as easy as taking away one of the dollor signs so instead of:

set variable[$$Print_Choices]

it would read:

set variable[$Print_Choices]

What this does for you is that as soon as the script is done executing the data in $print_Choices is effectively disposed. If you make it global, make that variable global it just hangs around and will actually be available to any script you execute which may or may not be what you intended. It's typically good practice to limit the scope of your variable to just the scripts that actually need it which is why you typically use local (single dollar) variables for needs like this.

[Søren Dyhr]

Are you saying that the "Restore" option is not necessary?

No it's fine, but the Enter Browsemode is daft, you are in browse mode!

--sd

[Veronica]

I made the change to local variable and double checked to make sure the gPrint_Choices was indeed global; and it is. Here is my Case statement for Scriptparamemter:

Case (Attendance_TO::gPrint_Choices = "View" ; "View" ;

Attendance_TO::gPrint_Choices = "Print" ; "Print" ;

Attendance_TO::gPrint_Choices = "PDF" ; "PDF" ;

Attendance_TO::gPrint_Choices = "Excel" ; "Excel" ;

"")

Just to re-inforce an earlier thought; It seems to make more sense to use the global field directly as the source for the (now) local variable in this case because I do have other scripts that use scriptparameters for other purposes and as I read somewhere else that would involve a lot of extra re-scripting.

Thanks for looking this over.

[comment]

It's hard to tell what the problem might be - based on your description it should work. Perhaps you could attach a simple file demonstrating the problem.

One thing that probably has nothing to do with problem at hand, but it stands out, is redundant calculations. For example, this:

Case (Attendance_TO::gPrint_Ch oices = "View" ; "View" ;

Attendance_TO::gPrint_Cho ices = "Print" ; "Print" ;

Attendance_TO::gPrint_Cho ices = "PDF" ; "PDF" ;

Attendance_TO::gPrint_Cho ices = "Excel" ; "Excel" ;

"")

seems to be exactly equivalent to:

Attendance_TO::gPrint_Choices

I also don't see the need to translate a script parameter to a variable. In fact, as you have noted, you could rely on the global field directly. If the script makes repeated references to the same, it could be a hair faster to send it up as a script parameter. But translating it once again to a variable is entirely redundant.

[Veronica]

Hi Comment,

Thanks for your help also. I appreciate the tip concerning just using the global field itself as the scriptparameter. I wish I could send a copy of the database but it is a copy of a version in use now and developed at a time when I knew much less than now. As the new school year is beginning I am cleaning up old techniques with new stuff I'm learning about. As this whole exercise.

I changed the source of my local variable to the global field itself. I removed the scriptparameter from the script button. I executed the script with the option to produce the report saved as a PDF and using the script debugger, I watched the script just march right over the: Perform Script "PDF Script".

I currently have over 300 scripts that if I could find out what is wrong with this script and process could help me reduce the number of scripts by 75-80%. Most of the existing scripts are for producing reports in different formats.

As you may surmise, it is so frustrating because the technique is working fine in the other database. The only thing that is different here is the file and table names. Thanks for your time.

[comment]

As I said, we need more information. If you could save a copy of the problem file, delete everything but the global field and the script, and post that, we might spot the problem. In fact, you might spot it yourself in the process.

[JesseSFR]

Since you have Filemaker 8 I would take a break point in put it at the top of your If...ElseIf construct and run it to that point. Then place your get(scriptparameter) in the data viewer.

What is the value that you see? You must be getting something that doesn't correspond with any of your conditions.

[Veronica]

I'll work on it. Give me a day.

Incidently, after I posted my last reply to you I got a request for a report from the other database. I changed the source of the local variable before running the report. And it dawned on me that the global field is in one table and the report data was from another table and it all worked perfectly. It seems to prove that the global field & local variable AND the report data don't have to be in the same Table occurance.

Thanks. Does anyone out there have any other output determination techniques?

[JesseSFR]

Yea globals are great.

I typically put all the globals in their own table for organization purposes. You actually don't even need a record and you can still put data in a global which really can blow your mind. Once you start thinking of globals as not actually being tied to any give table (except for when you explicitly need it of course) I think it becomes a lot easier to visualize things

Local Variables are also quite nice because they are temporary holders that just disappear as soon as the script they are running in finishes executing so you don't have to pollute your tables with more annoying globals.

[comment]

Does anyone out there have any other output determination techniques?

A custom dialog showing a calculation of say:

Attendance_TO::gPrint_Choices

&¶&

Get (ScriptParameter)

&¶&

$Print_Choice

could be pretty revealing. You can shift this step to various points of your script to determine where the problem starts.

Once you start thinking of globals as not actually being tied to any give table

I wouldn't go that far. Once you need them in a relationship, it becomes painfully clear they are very much tied to a table.

[JesseSFR]

(except for when you explicitly need it of course)

I one hundred percent agree with you 'comment'. That's why I included this in my post. I didn't mean to confuse. In general use, though using globals in relationships should be avoided.

[comment]

The thing is I don't **need** them to be tied to a table - quite the opposite, I would like them to be 'global', so I can define a relationship from TableA to TableB as:

TableA::globalFieldInTableC = TableB::SomeField

using globals in relationships should be avoided.

I don't think I agree with that - as with most blanket statements.

[Veronica]

I cut out a lot of the scripts. There are 3 test scripts that are appropo for this thread. There is a script section for them, "Test Report Scripts". The buttons for this exercise are Wheat or Peanut Butter colored. And the login is Test2, password is test2.

Stu_Info_Sys.zip

[Veronica]

My apologies to those who may have looked at my database and didn't get very far. The user name should be: test1 and the password admin

I think that should let you see all around the database and maybe help me solve my problem, (which has not yet been solved).

Stu_Info_Sys.zip

[JesseSFR]

Are you sure that's the username and password??? I can't seem to get into your file.

[Veronica]

My apologies to all who tried to get into my database example. I no longer remember the password I created to supposedly allow you access.

I suspect that I'm writing this to an audience that has already moved on and other commitments on my part have caused me to give up on this for a little while. If you are interested contact me at: [email protected]

Sorry and Thanks