Wrong date format for imports using server-side script

[PGageler]

My apologies if someone has already raised this, but I can't seem to find an answer anywhere.

Until recently, I managed the twice a day updating of a table with data from a txt file using a old computer acting as a robot to run the import script.

A month or so back, I thought I would "simplify" the process by scheduling the update to be done via a server-side script, with the txt file sitting in the Documents folder on the server. That all works fine, except that the date format comes in as m/d/yyyy when it runs on the server, instead of d/m/yyyy - which is how it works when the import was run under the robot solution or from my own client software.

I have checked the Region and Language settings on the Server that they are the same as my PC (Australian). I cannot see anywhere in the FMS configuration that I can set/check the date format being used - I have just assumed it would derived those from the operating system, but apparently not.

I have only just discovered this problem and it is causing some (until now undetected) problems, as other systems rely on the date information to trigger key business processes.

Any help would be greatly appreciated. Thanks

[jamesducker]

I have seen similar before, and don't believe there is a way of making FMS respect the host operating system's region settings.

Best plan would be to change the date format in the source .txt file, if you can. Alternatively consider importing the d/m/yyyy date in to a text field then adding a 'replace field contents' script step at the end of your import script, to copy the date from the text field to your date field.

Hope that helps.

James

[PGageler]

Thanks for your response James.

So as to be able to have consistent date format for all imports (regardless of whether triggered by the FMS schedule or manually by a user via the client), I have had to reconfigure the source data file so as to split the date information into three three components: Year, Month & Day, so that the final date in the database is a calculation based on these.

This is a major workaround and is a big disintentive for server-side imports for developers on on-US systems. I hope FileMaker look at this.

Phillip