Leaderboard

If you use this in a calculation, be sure to set the field Options > Storage Options to 'do not store calculation results'. Nice, Jeremy!

Okay, I have managed to reproduce the problem. It's a bug. 1. How to work around the bug: Use Insert Calculated Result[] instead of Set Field[]. 2. How to avoid the bug: Save a copy of your file as clone (no records) and import the records into the clone. The new file's date format will be YYYY-MM-DD and your script will work. 3. How to avoid the bug and follow the best practice of not having your script depend on any date format: Make your script do: Enter Find Mode [] Set Field [ Calendar::calDate; Date ( Get (ScriptParameter) ; 1 ; Year ( Get (CurrentDate) ) ) & ".." & Date ( Get (ScriptParameter) + 1 ; 0 ; Year ( Get (CurrentDate) ) ) ] Perform Find [] where script parameter is a number between 1 and 12 (there's really no good reason to send the month name as text, then spend 12 lines of code converting it to a number).

Actually, there were at least four of them: EventScript, DoScript, zippScript and FMI's own plugin example.

Hi Siroos, Thank you for providing the sample file. :-) Unfortunately it isn't enough for us to have a clear sense of what you are wishing to accomplish. It normally requires a SCRIPT to perform a script action. Custom functions are functions used in calculations and calculations can't act. There was a plugin, I forget its name, which would fire a script based upon a field-value change. I quit using it 15 years ago because it was too dangerous and unpredictable. Michael, Tom or Wim might remember its name. Why wouldn't a Resume Script work for you? Anyway, I've attached a revised file showing how I could provide you with your request immediately above. I hope it is helpful but I suspect, as Tom points out, you need to rethink your approach instead. testREV.fmp12 By the way, I included passing a script parameter back. Sometimes a small thing can help in reconsidering an approach.

Try the Middle() function: Middle ( full_ticket_number ; 3 ; Length ( full_ticket_number ) - 3 ) If all ticket numbers have the same length, you can shorten it to: Middle ( full_ticket_number ; 3 ; 13 )

For many clients I use a different container data folder so that the FMS backup schedule only backs up the FileMaker database files, and I use CrashPlan for backing up the container folder. Unfortunately, 360Deploy expects the folder RC_Data_FMS to exist only in the database folder and fails with a 500 error if that path doesn't exist. Is a fix for this on the radar? Some of my solutions have many GBs worth of container data and I'd rather not have FMP back up all of this data every time a backup schedule runs. Dave

XSLT seems to me like it would probably be the fastest. Exporting the CSV to disc and importing can also be advantageous if your schema is already a convenient match for that or you're willing to adapt your schema for that. The built-in JSON functions have many virtues. Execution speed is not one of them. In every test I've run, GetValue on return-delimited lists leaves the built-in JSON functions in the dust. The MBS plug-in handles JSON differently in a way that makes it much faster (MBS does what I was hoping FileMaker would do with an in-memory data structure), if you're into plug-ins. If you like sticking with return-delimited lists, you can make the processing of a large list go faster by pruning the list as you go: Set Variable [ $value ; GetValue ( $list ; 1 ) ] Set Variable [ $list ; Replace ( $list ; 1 ; Length ( $value ) + 1 ; "" )] This makes the parsing of the whole list work in roughly O ( N^1.5 ) time, rather than O ( N^2 ).

it's probably reading the field value as text. If you want to be safe, do a getasnumber( ) around what you compare