Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

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

Recommended Posts

Posted

I'm having an issue when running a script on the server. I have a variable set called $filterDate. I run a Perform Find [Restore] finding in a field on one layout with the criteria $filterDate. This find works. However, later in the same script, I use the same Perform Find [Restore] on another date field on a different layout and it returns a 500 error (I set a send mail step just after this to trap the error and notify as you cannot debug on the server side). The strange this is if I run this script on the client side, it works perfectly.

I then disabled the Perform Find and replaced it with three steps. Enter Find Mode, Set field x to $filterDate, and Perform Find [ ]. Strangely enough, even on the server this works. Any ideas?

Attached is the script in a pdf format. Starting on page 3, the pink highlighted line is the find that works. The yellow is the broken one, and the orange lines are the fix.

Posted

OK, let's work thru the script. I think if I confirm your purpose, then we can come up with better techniques.

Why capture Get (AccountName) into $$user?

Set Filter Date section

What is the purpose of this? You can set $filterDate without creating any records. Btw, you set $filterDate twice.

Let's start there.

Posted

OK, let's work thru the script. I think if I confirm your purpose, then we can come up with better techniques.

Why capture Get (AccountName) into $$user?

Set Filter Date section

What is the purpose of this? You can set $filterDate without creating any records. Btw, you set $filterDate twice.

Let's start there.

The script is going to be expanded later and will need the user info. I just use the variable $$user for ease of writing the scripts. Is there a downside to it as opposed to calling Get ( AccountName ) over and over?

The script posted has been cleaned up since and does not call $filterDate multiple times. As for setting it without creating a record, again, the script has been cleaned up since then. This script was originally written to run on both server and client. So I had the step of creating the record so that the user can set the $filterDate via a dialog box. I needed to create the record to allow the user to type the date into field via the dialog (something I have wished for filemaker to implement, that you can set a variable directly via dialog box, rather than have to use input fields). The script has been split into two separate scripts. Once for server, one for client.

Posted

Well, if this isn't the script, then I won't waste time on it.

Are you familiar with global fields? They can be used in dialogs.

Posted

Of course I'm familiar with Global fields. That is in fact a global field. Are you saying that a global field can be set without a record being present, i.e., when there are 0 records? If so, I was not aware of that.

I'm sorry, I didn't mean to waste your time on my script. I was really only looking for assistance as to why restored find won't run on the server, where it WILL run on the client side.

Posted

Yes to global field setting.

I saw so many problems in your script that I couldn't get past them to see why your find didn't work. I did see a Delete All Records just before the Find. Perhaps that is why you received an error? btw, Replace is not multi-user friendly. It cannot be counted on (and won't report which record could not be replaced).

Feel free to post the actual script (or sample file), if you're interested in feedback.

Posted

The Delete All Records removes records from a previous find which were invalid records because they already exist in the system. I cannot see how this would affect the issue at hand.

Put simply, I cannot understand why:

Perform Find [ Specified Find Requests: Find Records; Criteria: SecPricesClosingCallBucket::date: “$filterDate” ] [ Restore ]

would not work on the Server but does work on the Client and:

Enter Find Mode [ ]

Set Field [ SecPricesClosingCallBucket::date; $filterDate ]

Perform Find [ ]

works on both Server and Client. Are they not essentially the same thing?

Finally, what would you recommend instead of Replace, a looping script? I am not worried about the typical error of not being able to set a field because a client is in the record because these are records that the clients do not have access to.

Posted

Are you saying that a global field can be set without a record being present, i.e., when there are 0 records? If so, I was not aware of that.

You can put that global in any table that does have records and reference it from there. Then there's no reason to create a record for user input.

Curious as to why you would have a global field for input in a table with 0 records? Even in a globals table you would have at least one record to establish the values.

Just an observation :)

Posted

Yes, they are essentially the same thing (and I prefer the latter, bcs I can more easily read the script). So, I would need to "see" the problem (and the actual script) to truly understand what is happening. What version of FMS are you using?

I would use a transaction to edit many records or a loop. Depends if it all must happen or nothing should happen.

Posted

ok, to stick to the topic ;)

why doesn't the search work on the server? if i let run a similar script it doesn't work on the server, but it works on a client. is there a sample search and then import somewhere working with those conditions?

cheers

Posted

Strangely enough, I have been able to solve the problem completely by change the Find[Restore] to Enter Find Mode, Set Field..., Perform Find. This works perfectly so I have given up on the other approach as nobody seems to have an idea why that could be.

Posted

unfortunately no luck yet...

here my two scripts:

File 1 which fetches data (from file 2 among others):

post-90858-0-60934600-1330431048_thumb.p

File 2 which holds data:

post-90858-0-01326500-1330431088_thumb.p

result: no EMail sent, no records created in File 1

This topic is 4653 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.