Have experienced no issues updating my solution using OttoFMS on US servers.
I have tested it on 2 different servers in Canada with the locale set to Canada.
I use the separation model, so the interface file is set to “Replace” and the data file is set to “Migrate”.
After updating, scripts that pass a date from the interface file to the data file enters invalid data into date fields (data entered = ?).
I have then used my previous updater that I built using FM and the Migration Tool and it fixes the problem.
I have solved the problem by leaving the option “Destination Locale” empty, but that presents another issue where date fields do not display the correct format in WebDirect.
The problem is that the interface file that is “Replaced” needs to have the locale set.
How I solved this in the updater that I built was for the interface file I had a “Copy” file AND a “Clone” file. I would then use the migration tool to migrate the NEW copy with the NEW clone and delete the old interface file.
Hi Nick,
That is a interesting case. I am surprised that hasn’t come up before. But maybe most people don’t regularly deploy to two countries?
We could automate the process you describe. But somewhere in the back of mind I have an idea that this might be simpler.
What happens on WebDirect if you open the file first with FileMaker pro on that server? Does the file then work correctly in Web Direct? Does opening the file with Pro set the local properly. If so I wonder if just running a Post Deployment script in the UI file would do it?
Just a guess really.
maybe some others on the forum will have more insight. @john_r deals with locales quite a bit I believe.
Will give it some more thought
Todd
Maybe you could convince FM to make a function in the migration tool to only set the locale of a file without doing a complete migration of the file
The act of cloning then means that the ‘first’ machine you open it on passes in the locale information from that machine, Server or Pro. And particularly if you have use defaults from this file on
The data Migration Tool gives you the opportunity to force the locale information at the time of the data being poured in, regardless of the home server locale. So you can end up with a French file hosted on a German server for instance.
As your interface is just being replaced then you are not going through this process.
Have you tried doing a migrate on the Interface file to? The act of cloning and filling will surely offer the opportunity to change the locale in the process.
The interface file is a COPY, so opening it in Pro does not change anything.
I could possibly MIGRATE the interface file and any new records that need to be added would have to be created with the post migration script.
I have come up with a solution.
I am going to migrate the interface file so it will have the locale set during deployment.
Before that I will move all records that need to be in the interface file (i.e. html code) into a new file just to hold those records.
Would you copy those records into the interface file in the post deployment script, or will just referencing the tables in the new file not make a difference when it comes to performance?
Hi Nick,
I would do it with a Post Deployment script. That is just the sort of thing they were designed for.
Todd
Do you think there is any performance difference if I permanently move some of these tables (i.e. HTML code for web viewers) to a new file and changing the TO’s in the interface file to the new file?
I doubt there will be any performance impact
Todd