Object text import/export and date formats

jbgrobler

Is there some way of making a suggestion to Microsoft to change the import/export behavior of objects when using the text format?

- I do not want FOB imports because I need to do code merges.
- Doing merging requires the use of the text format.
- The official updates from Microsoft is using American date format ("M/DD/YY") in the text files.
- Exporting modified objects is using the server date format (in my case Canadian "DD/MM/YY") in the text files.

After a merge when attempting to import the objects I get invalid date errors. I have to spend time and edit all the dates in the merged objects, as well as new objects, then switch the server to American date format, import, and then switch the server date format back.

Switching the server date format back and forth really should not be required to do an import. Why not use a fixed date format for the import/export? It is only used by NAV itself anyway. Maybe use ISO instead so there is no confusion (yyyy-mm-dd).

This is driving me up the wall. Sigh.

jglathe

This minor nuisance will soon be only background noise ;-) Anyway, you are right about that. But my impression was that something regarding the text format was changed in CU9, build 37221. That doesn't change the problem with the builds that are actually in use, like NAV2009R2 build 32012, though. The recommendation is to use W1 (ENU) language setting when compiling/exporting the objects. But this doesn't really help. So I say f*ck this and use my local language setting all the time. For all objects that you actually can compile and export, this works well enough. I still get the occasional "artifacts" changeset, though. To reduce the problems it's a good idea to only import merged objects by .txt. It is really seldom that a .txt fails on a date problem in my experience. More often are issues with double control/variable IDs, indentation errors, text constant special character errors (especially french language layer can be a b*tch), syntax mismatches, and double comment sections. And my favourite: New fields in standard tables where you also have fields. If these fields are referenced in the C/AL then it's a bit of a run-around and interim .fobs and additional databases to get them together.

with best regards

Jens