Solution: set NLS_LANG!
More: I had the same problem, and actually had the same situation as described in the study of Sergei Bazarnik. Using bind variables, it works, and without them it is not.
The SOLUTION is to set NLS_LANG in the right place. Since I have a Windows server, I installed it in the Windows HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ORACLE\KEY_OraClient11g_home1 under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ORACLE\KEY_OraClient11g_home1
Please note that the location in the register may vary, so the easiest way is to find the registry for the string "ORACLE_HOME". Also other systems like Linux, Unix may install it differently (export NLS_LANG ...)
In my case, I put "NLS_LANG"="CROATIAN_CROATIA.UTF8" . Since I did not have such a set of variables, it went over to the default value. After changing the registry, you must restart the process. In my case, I restarted IIS.
Regarding the reason why it works with bind variables, it may be because it actually happens on the server side, but in fact it does not happen on the client side. Thus, even this database can insert the correct values - before this happens, the client makes unwanted corrections, since it believes that this should do it. This is because NLS_LANG uses a simpler code page by default. But instead of doing a useful task, it creates a problem that (as shown in the study, is difficult to understand).
If you have several versions of oracle, be sure to fix all the versions in the registry (in my case, Oracle 10 had a valid configuration, but Oracle 11 did not have NLS_LANG at all).
Veljac
source share