Assuming you already checked your system preferences formats...
This might occur if the system settings used when the file was created were different as your actual system settings.
You can set your file behavior in this case on File menu > File Options… and click Text tab.
Yep I have already checked that. If I type 28/03/2013 manually into the field when in find mode it returns all records with that date. If I script it as above I get an error 500. When I step through the script in script debugger I get an error 500 when I get to the script step Set Field [Tablename::Datefield; "28/03/2013"]. So I am assuming that there is a problem with using European date formatting when performing a find and setting a date field with the european date format (DD/MM/YYYY).
Thanks for your speedy response.
And I am now definitely able to replicate. The steps i took :
Even the dates were immediately displayed as expected (DD/MM/YY) and a regular, manual search worked, the script get the 500 error and, of course, failed.If i then create a clone of the file, open the clone and import all datas from the original file, the script is now working on the brand new file.Bon courage,
- Restarted my MacBook Pro (10.9.4) after changing system preferences as US, so MM/DD/YY date formatting
- Created a brand new file with a date field, formatted "as entered" on my layout.
- Entered some record with dates including 03/28/2013
- Restarted my MacBook Pro (10.9.4) after changing system preferences as Australian, so DD/MM/YY date formatting
- Created and performed your script
As an additional note, if i opened the "U.S. native file" in Australia the 28 March 2013, the Get (CurrentDate) fonction returned "28/03/2013" on Data viewer, although GetAsDate ( "28/03/2013" ) returned "?".
Thus, if i used this function Get (CurrentDate) on the Set Field step, instead of GetAsDate ( "28/03/2013" ) the script worked correctly.
Please note I did all theses testings locally, without any sharing. Even if I can perfectly understand the actual behavior, since a file (and its scripts!) can be accessed by different clients with different regional settings, my conclusion is : Sometimes, FileMaker is incredibly clever, whereas other times, he's just an honest citizen .
Thanks for your speedy reply. You are 100% correct. Our problem was with our interface file being created on a system with a different date format. Cloning the interface file has fixed the issue. Luckily we use the data separation model and all our data files were created with Australian formatting. I am very happy that we don't have to go down the path of importing all our data into clone files, that would have been a really big pain. Thanks Fred!