ado.net - Which is locale-aware: OleDb.Currency or OleDb.Decimal? -
It is two times that I have an access database and a table with the MS Access Currency field. In the United States, my clients use decimal values like 1.23 and in Ecuador my clients use the number of decimal as 1,23.
I have some ADO legacy codes and I have tried to make ADODB parameters with type addecal type, either in the case adCurrency, access to data after reaching the ADODB command 1.23 (US) Expected) and comes in the form of 123.00 (not expected) for Ecuador.
In my .NET code, I have tried OleDb.Currency and OleDb parameter with OleDb.Decimal It seems that OleDb.Currency is locale-aware but not OleDb.Decimal.
My head is spinning. Does anyone know the correct way to use the correct ADO and NDT parameters for the international currency for my heritage code because our codebase goes ahead?
Thank you!
OK, after some extra digging, it appears that "currency" type "decimals "Prefer more than the types. In other words, using ADCurrency for ADO or OleDb.Currency will be used for decimal values to be saved in MS Access currency areas.
Just for someone else, when I got this - I got very strange behavior. The ADO case is as follows:
My code installed a new ADODB command and set the Parameters collection - Some typing, such as adCurrency, I started updating many records in my database. I reused the same command object for each update and all the parameter fields before the next update block started Called a method to reset. This has resulted in poor data in my areas (see the initial problem described above). I tried several things to fix this and were unsuccessful. Also, to ensure that there was no relation to relationship, I also excluded the call for my reset permit method.
Fix: Instead of reusing the command object, I finally decided to add new command objects before each update block. Suddenly, all of my local values appear in the proper reach regardless of my locale settings.
In summary, it appears that after executing some executed work on my order object, such as the adCurrency parameter subsequent updates were broken. By the way, the results were as follows: A 4,32 value would appear as a access to 432 (this is Ecuador currency formatting). My code was not ultra-complex and I would not post it here, but two of us were looking very hard on this and we did not see anything that could explain it. In fact, the idea of creating a new example came when we wrote a test app which is called only an update and the exact code worked in only one test.
Be careful to reuse ADO command objects Multiple updates If you are writing a localized app
Comments
Post a Comment