3 ASCII codes can't be typed into NAV, affects language

josephdewey

You might be wondering, why would I care if you can't type three ASCII characters into NAV? It has to do with how NAV does foreign language characters through code pages, so it stores the foreign language characters as ASCII characters.

There are three ASCII characters that cannot be typed into NAV 2009 Classic Client, which are ¶, ¤, and §. This is a problem on foreign-language entry, for example Thai, because when typing Thai on the keyboard, the characters get sent as ASCII characters to NAV. There is no error when this happens, just no character shows up.

The ALT Codes are a good way to simulate this error. Here are the ALT Codes for the affected characters, that don’t work in NAV:

• ¶, ALT+0182
• ¤, ALT+0164
• §, ALT+0167

Here are a couple of ALT codes that do work in NAV:

• £, ALT+0163
• ¦, ALT+0166

Note that you must hold ALT down the entire time you are entering the ALT code. So, to enter the ¤, you depress the ALT key, press 0, 1, 6, 4, and then lift up the ALT key.

To test this, go to an outside application, such as Word or Notepad, and enter the ALT codes shown above. Then go to NAV 2009 Classic, and enter the ALT codes shown above. You will notice that on Word and Notepad, that all of the characters are displayed. You will notice that on NAV 2009 Classic, then the characters of ¶, ¤, and § will not be displayed. Nothing shows up when these characters get entered.

I think that NAV were to fix the issue that’s described with the ALT codes, that it will automatically fix the Thai language issue. And all of the ALT codes work, besides those three that I mentioned.

Another way to simulate this error is to install the Thai keyboard on your computer, and to try to type the characters of ค, ง, and ถ into NAV.

I tested this on NAV 2009 SP1 and R2. This has been fixed in the RTC, but I'd really like to find a workaround in the Classic Client. And, copying and pasting these ASCII characters is a workaround, but I'd like something better than that.

Has anyone come across this before? Have you come up with any workarounds? I've only run into it with the Thai language, which is one character per ASCII character. But I think that on another language, like Chinese (or Japanese or Korean), where there are multiple ASCII characters, then users would complain about a few Chinese characters getting entered incorrectly. Anyone running the classic client should be able to duplicate this issue.

Thanks in advance for any comments!

Sog

Ascii doesn't exceed 127. It's Ansi that you mean.
As long as NAV isen't built on Unicode, language issues will remain present in NAV. And I see this as a language issue.

josephdewey

Thanks for pointing this out, I do mean ANSI, the characters between 128 and 255 (Or Window-1252). I never knew that ASCII was just the first 128 characters. Thanks!

And, I do agree that it would be awesome if NAV had Unicode support. But, until that happens, I'll probably still have my issue.

ta5

Hi
Yeah, waiting for unicode

Anyway, when working with SQL I have seen a strange issue. After storing such characters in a key field (e.g. Search Name in Contact), NAV Backup was not possibly anymore, the process stopped reminding "There is a invalid character..." The valid and invalid characters depend on the collation of the db, but input of invalid characters seems to be possible, at least under certain cirumstances.

Did you encounter similar problems?

Thanks
Thomas

josephdewey

We've still been able to do NAV backups while using the ANSI code pages to display special characters. But, we mostly do SQL Server backups, because the NAV backups are way too slow. I'll watch out for problems, though. Thanks!

iceborg

For what it is worth,

I am able to get those characters in NAV Classic (R2) with the mentioned ALT codes ( I see of ¶, ¤, and §).
If I switch my System Locale to Thai and use the same ALT Codes in NAV, characters appears in NAV.

Of course it works in RTC as it is Fully Unicode based and will go By your Display/Windows Language and not the underlying OEM Code page.

The problem with Code fields and Classic Client is due to the UPPERCASE functionality which is not relevant for many Languages not based on Latin Characters.

josephdewey

This is really good information. Thanks!

I also tested this on the R2 version that Microsoft had at Convergence 2012, and it had this same problem. the problems. So, it's nice to know that not all R2 releases have this issue. Maybe it has something to do with the US localization.

I didn't realize that RTC was full Unicode, so thanks for that information. Maybe we'll be migrating to the RTC a lot quicker now.

Thanks!

superpuz

well, I'm not well familiar with encoding and sort of stuff, and I have some issue though and need a suggestion.

I installed NAV 2009 R2 (ID version) on a computer using Japan Language. I cannot enter to the classic due to the different language. But I can connect to the NAV Server using RTC from this computer. And after several trial opening pages and reports, it seems to functioning normally. But my concern is when the user entering data from this NAV Client (which has Japan Language and/or Keyboard) will it be a problem to other users to read the data later? And how to prohibit the user to entry a 'strange' character to the database? is it enough by activating the validate code page option?

Thanks in advance.

rdebath

I can type these characters without any problems.

ta5 wrote:

Anyway, when working with SQL I have seen a strange issue. After storing such characters in a key field (e.g. Search Name in Contact), NAV Backup was not possibly anymore, the process stopped reminding "There is a invalid character..." The valid and invalid characters depend on the collation of the db, but input of invalid characters seems to be possible, at least under certain cirumstances.

Did you encounter similar problems?

The only time I've encountered this sort of problem is when the character sets have been forced. Thai on windows uses MS codepage 1258 for both the OEM and ANSI codepages so you don't have to worry about the OEM codepage. (Which makes things easier)

Go into File->Database->Alter on the Collation tab "Validate Code Page" should be true.
If the "Collation Description" cannot be set to Thai or Codepage 1258 with this flag true your PC in NOT setup properly for the Thai locale.

Once both the PC and the database are setup correctly you shouldn't have any problems.

PS: NAV 2013 uses Windows Unicode, you still can't enter Klingon but basic Unicode works.