Russian Code field problems with WW

lzr

We have a customer who uses WW version of 4.0 in Russia. When we try to validate some russian text into a code field (such as post code or search name) it will be totally different than it should be like. We have tried the same procedure with Cronus RU and there it works like it should. This is not client dependent since we tried the same client on both.
Anyone have any experience in this field?

David_Singleton

If you open your fin.stx file, you will find somehting like this:

// casetable
00043-00100-200-1: aA,bB,cC,dD,eE,fF,gG,hH,iI,jJ,kK,lL,mM,nN,oO,pP,qQ,rR,sS,tT,\
00043-00101-200-1: uU,vV,wW,xX,yY,zZ,?š,‚?,ƒ¶,„Ž,…·,†?,‡€,ˆÒ,‰Ó,ŠÔ,‹Ø,Œ×,?Þ,‘’,\
00043-00102-200-1: “â,”™,•ã,–ê,—ë,›?, µ,¡Ö,¢à,£é,¤¥,ÆÇ,ÐÑ,äå,çè,ìí

// sorttable
00043-00110-200-1: " ",a …ƒÆ¦Aµ·¶Ç,bB,c‡C€,dÐDÑ,e‚Šˆ‰E?ÔÒÓ,fF,gG,hH,i¡?Œ‹IÖÞ×Ø,\
00043-00111-200-1: jJ,kK,lL,mM,n¤N¥,o¢•“ä§Oàãâå,pP,qQ,rR,sáS,tçTè,u£—–Uéëê,vV,wW,\
00043-00112-200-1: xX,yì˜?Yíš,zZ,‘„’Ž,›”?™,†?,0,1,2,3,4,5,6,7,8,9,<60>0>,<1>,<2>,<3>,\
00043-00113-200-1: <4>,<5>,<6>,<7>,<8>,<9>,<10>,<11>,<12>,<13>,<14>,<15>,<16>,<17>,\
00043-00114-200-1: <18>,<19>,<20>,<21>,<22>,<23>,<24>,<25>,<26>,<27>,<28>,<29>,<30>,\
00043-00115-200-1: <31>,!,"""",#,$,%,&,',(,),*,+,",",-,.,/,:,";",<,=,>,?,<64>,[,\,],^,\
00043-00116-200-1: _,`,"{",|,"}",~,<127>,œ,ž,Ÿ,¨,©,ª,¬,«,­,®,¯,°,±,²,³,´,¸,¹,º,»,¼,\
00043-00117-200-1: ½,¾,¿,À,Á,,Ã,Ä,Å,È,É,Ê,Ë,Ì,Í,Î,Ï,Õ,Ù,Ú,Û,Ü,Ý,ß,æ,î,ï,ð,ñ,ò,ó,ô,\
00043-00118-200-1: õ,ö,÷,ø,ù,ú,û,ý,ü,þ,<255>

These two tables determine the sorting of data, and the mapping of lower to uppercase.

Thus the sorting is dependant on the language version of Navision. There really is no general solution to this, since you probably also need to maintain Swedish sorting for your other data.


When you use a Rusian database that was create using a Russina STX file, all should work fine.

Unicode... its coming... jsut around the corner (or at least thats what I have bene hearing since they moved Navision from DOS to Windows.

By the way, the problem of sorting is that the sorting is used to build keys, so it can't be just changed on the fly. (The sorting and case conversion issues are tightly related).

lzr

David Singleton wrote:

If you open your fin.stx file, you will find somehting like this:

// casetable
00043-00100-200-1: aA,bB,cC,dD,eE,fF,gG,hH,iI,jJ,kK,lL,mM,nN,oO,pP,qQ,rR,sS,tT,\
00043-00101-200-1: uU,vV,wW,xX,yY,zZ,?š,‚?,ƒ¶,„Ž,…·,†?,‡€,ˆÒ,‰Ó,ŠÔ,‹Ø,Œ×,?Þ,‘’,\
00043-00102-200-1: “â,”™,•ã,–ê,—ë,›?, µ,¡Ö,¢à,£é,¤¥,ÆÇ,ÐÑ,äå,çè,ìí

// sorttable
00043-00110-200-1: " ",a …ƒÆ¦Aµ·¶Ç,bB,c‡C€,dÐDÑ,e‚Šˆ‰E?ÔÒÓ,fF,gG,hH,i¡?Œ‹IÖÞ×Ø,\
00043-00111-200-1: jJ,kK,lL,mM,n¤N¥,o¢•“ä§Oàãâå,pP,qQ,rR,sáS,tçTè,u£—–Uéëê,vV,wW,\
00043-00112-200-1: xX,yì˜?Yíš,zZ,‘„’Ž,›”?™,†?,0,1,2,3,4,5,6,7,8,9,<60>0>,<1>,<2>,<3>,\
00043-00113-200-1: <4>,<5>,<6>,<7>,<8>,<9>,<10>,<11>,<12>,<13>,<14>,<15>,<16>,<17>,\
00043-00114-200-1: <18>,<19>,<20>,<21>,<22>,<23>,<24>,<25>,<26>,<27>,<28>,<29>,<30>,\
00043-00115-200-1: <31>,!,"""",#,$,%,&,',(,),*,+,",",-,.,/,:,";",<,=,>,?,<64>,[,\,],^,\
00043-00116-200-1: _,`,"{",|,"}",~,<127>,œ,ž,Ÿ,¨,©,ª,¬,«,­,®,¯,°,±,²,³,´,¸,¹,º,»,¼,\
00043-00117-200-1: ½,¾,¿,À,Á,,Ã,Ä,Å,È,É,Ê,Ë,Ì,Í,Î,Ï,Õ,Ù,Ú,Û,Ü,Ý,ß,æ,î,ï,ð,ñ,ò,ó,ô,\
00043-00118-200-1: õ,ö,÷,ø,ù,ú,û,ý,ü,þ,<255>

These two tables determine the sorting of data, and the mapping of lower to uppercase.

Thus the sorting is dependant on the language version of Navision. There really is no general solution to this, since you probably also need to maintain Swedish sorting for your other data.


When you use a Rusian database that was create using a Russina STX file, all should work fine.

Unicode... its coming... jsut around the corner (or at least thats what I have bene hearing since they moved Navision from DOS to Windows.

By the way, the problem of sorting is that the sorting is used to build keys, so it can't be just changed on the fly. (The sorting and case conversion issues are tightly related).

Thank you for your answer!

So you mean that the stx file which was used to create the database is the one who sets how code fields should be converted?

These values should then be inside the database somewhere, they can not be manipulated afterwards?

It doesn't matter at all on the stx files of clients connected to the database after it is created?

David_Singleton

lzr wrote:

...

These values should then be inside the database somewhere, they can not be manipulated afterwards?
...

No unfortunately not. The job to do that would be huge. You would need to access every field tha has been case converted, and reverse the original case conversion used, then reapply the now logic. I couldn't even visualize how you would do that. On the sorting side, you could do a complete reindex, but that would just take time I guess.

I am not sure where the sorting and case mapping is stored. I don't see that it could be in the database, it really needs to be stored witht he company data. If it wasn't then importing a Company backup into a differnt database would do a resort. In fact if the Mapping is stored in the database, then it should be a simple process to just create a backup, build a new database using Russian STX, and then restore into that DB.

It would be a pretty easy toest to do with a small Cronus database.

Please if you do do the test, plese let us know the result.

Thinking further, if its SQL, then the colation is stored at the database level, and Navision tried to always make SQL and C/SIDE operate the same, so maybe it is in the database, and not the company (aka backup).

lzr

I will let you know how it goes. Right now we are testing to create a russian database and restore the data.

Thanks a lot for your answers