I am working on internationalizing legacy VB component which was ported out to
 VB.Net   This code base is very old and it does something no body recommends
 in the data service component.  Changing the way it works is not an option 
 so no point discussing that here.  

The problem is SQL query is dynamically generated in the data service 
component by
doing a simple string concatenation.  Being VB it doesn’t even do proper 
casting
it just attaches it string query.  It has been working fine last 10 years 
and this year
they decided to internationalize the code base.  The SQL query breaks when 
locale
is set to languages that uses comma instead of period as decimal.  For example

INSERT INTO PURCHASING (COL1, COL2) VALUES (123.45, ‘TEST’)

Now becomes

INSERT INTO PRUCHASING (COL1, COL2) VALUES (123,45, ‘TEST’)

This is not a proper SQL query.  This happens because conversion of double 
to string includes locale formatting and since every assembly runs in a same
thread monolithically I can not even use tricks like resetting the running 
thread
culture (it will disrupt formatting and currency display). How can I so that
SQL query is generated right?  

Thank you.

UW schrieb:

> I am working on internationalizing legacy VB component which was ported out to
>  VB.Net   This code base is very old and it does something no body recommends
>  in the data service component.  Changing the way it works is not an option 
>  so no point discussing that here.  
> 
> The problem is SQL query is dynamically generated in the data service 
> component by
> doing a simple string concatenation.  Being VB it doesn’t even do proper 
> casting
> it just attaches it string query.  It has been working fine last 10 years 
> and this year
> they decided to internationalize the code base.  The SQL query breaks when 
> locale
> is set to languages that uses comma instead of period as decimal.  For example
> 
> INSERT INTO PURCHASING (COL1, COL2) VALUES (123.45, ‘TEST’)
> 
> Now becomes
> 
> INSERT INTO PRUCHASING (COL1, COL2) VALUES (123,45, ‘TEST’)
> 
> This is not a proper SQL query.  This happens because conversion of double 
> to string includes locale formatting and since every assembly runs in a same
> thread monolithically I can not even use tricks like resetting the running 
> thread
> culture (it will disrupt formatting and currency display). How can I so that
> SQL query is generated right?  
> 
> Thank you.
> 

If i got you right, you can use this to transform your double values 
into the right language:

Dim dbl As Double = 1.2
Dim en As New CultureInfo("en-GB")

Console.WriteLine("With    CultureInfo: {0}", Convert.ToString(dbl, en))
Console.WriteLine("Without CultureInfo: {0}", dbl)

Michael Neßlinger

Thank you for your response.

   Is there any 'trick' or 'gimmick' I can use without add/change existing 
code?

   For example :

               add attributes in the assembly info file and fix the assembly 
in certain
               culture.

               or

               change somthing in the .Net config file to apply above effect 
or 
               some how redefine way .Net handles certain casting (this will 
effect
               how UI displays numbers so need way to get around that as well
               if works)

  Any ideas?  Would contacting Microsoft support have better idea?

Thank you.

"Michael Nesslinger" wrote:


> UW schrieb:
> > I am working on internationalizing legacy VB component which was ported out to
> >  VB.Net   This code base is very old and it does something no body recommends
> >  in the data service component.  Changing the way it works is not an option 
> >  so no point discussing that here.  
> > 
> > The problem is SQL query is dynamically generated in the data service 
> > component by
> > doing a simple string concatenation.  Being VB it doesn’t even do proper 
> > casting
> > it just attaches it string query.  It has been working fine last 10 years 
> > and this year
> > they decided to internationalize the code base.  The SQL query breaks when 
> > locale
> > is set to languages that uses comma instead of period as decimal.  For example
> > 
> > INSERT INTO PURCHASING (COL1, COL2) VALUES (123.45, ‘TEST’)
> > 
> > Now becomes
> > 
> > INSERT INTO PRUCHASING (COL1, COL2) VALUES (123,45, ‘TEST’)
> > 
> > This is not a proper SQL query.  This happens because conversion of double 
> > to string includes locale formatting and since every assembly runs in a same
> > thread monolithically I can not even use tricks like resetting the running 
> > thread
> > culture (it will disrupt formatting and currency display). How can I so that
> > SQL query is generated right?  
> > 
> > Thank you.
> > 
> If i got you right, you can use this to transform your double values 
> into the right language:
> 
> Dim dbl As Double = 1.2
> Dim en As New CultureInfo("en-GB")
> 
> Console.WriteLine("With    CultureInfo: {0}", Convert.ToString(dbl, en))
> Console.WriteLine("Without CultureInfo: {0}", dbl)
> 
> Michael Neßlinger
> 

Hi UW!



> The problem is SQL query is dynamically generated in the data service 
> component by doing a simple string concatenation.  


This is the main problem! Never ever do string-concatenattion! This will 
open a wide door for SQL-injections!
Pass your parameters as "Parameters"!

Unnamned-Parameters:
INSERT INTO PURCHASING (COL1, COL2) VALUES (?, ?)

Names-Parameters:
INSERT INTO PURCHASING (COL1, COL2) VALUES (@col1, @col2)


Then you don't have this problem anymore!


> INSERT INTO PURCHASING (COL1, COL2) VALUES (123.45, ‘TEST’)
> 
> Now becomes
> 
> INSERT INTO PRUCHASING (COL1, COL2) VALUES (123,45, ‘TEST’)


You could use x.ToString(Culture.InvariantCulture)


-- 
Greetings
   Jochen

    My blog about Win32 and .NET
    http://blog.kalmbachnet.de/