ADO .NET 1.1 issue with stored proc params missing but only if culture is Turkish.

  • Thread starter Thread starter gcxmuirhead
  • Start date Start date
G

gcxmuirhead

I have an application that is localized into a number of cultures
(Turkish is one) and a number of stored proc calls are failling when
the site is run in Turkish but not in any other language, but not all
procs fail. I am using framework 1.1, standard datasets and table
using SQLDataAdapter update clls.

e.g.
Stored proc with 3 params
InsertOrderProducts(@productID int, @data1 bit, @data2 int)
DataTable dt (with columns that match and valid data)
SQL parameter collection that specifies the params and the
corresponding table column.
A call to SQLDataAdapter.Update(dt)

The application is doing more than that but in a nut shell that is the
problem and as a result users of my site cannot place orders in if the
culture is Turkish if they change culture to English and proceed the
order can be placed (very ugly work around).

HELP.

Thanks,
GM
 
I have an application that is localized into a number of cultures
(Turkish is one) and a number of stored proc calls are failling when
the site is run in Turkish but not in any other language,but not all
procs fail. I am using framework 1.1, standard datasets and table
using SQLDataAdapter update clls.

e.g.Storedprocwith 3params
InsertOrderProducts(@productID int, @data1 bit, @data2 int)
DataTable dt (with columns that match and valid data)
SQL parameter collection that specifies the params and the
corresponding table column.
A call to SQLDataAdapter.Update(dt)

The application is doing more than that but in a nut shell that is the
problem and as a result users of my site cannot place orders in if the
culture is Turkish if they change culture to English and proceed the
order can be placed (very ugly work around).

HELP.

Thanks,
GM
Click to expand...

I am looking into what may be a related problem so the following may
be helpful to you.

I have been able to find a probable cause. Apparently Turkish (and
only Turkish) has 2 letter "I"s (the have both with and without dot in
BOTH upper and lowercase!). What seems to happen is that an English I
gets converted to one of the Turkish unusual "I"s, but when this is
looked up in the backend code it is not a recognised name (since it is
a different character). In my case I cannot see any effect on the I
in the error message as at that time it does get converted back to the
English I. It is possible that it would only happen if a lowercase i
with dot is expected to match an uppercase I without (via a case
convert done in the wrong symbol set, including automatically by a
programming language that is case blind).

The following URLs relate to this problem (in no particular order).
http://www.dotnet247.com/247reference/msgs/57/286776.aspx (related
problems)

http://www.dotnet247.com/247reference/msgs/42/214380.aspx (related
problems)

http://www.microsoft.com/globaldev/DrIntl/columns/001/default.mspx#Q2
(see the comment at the bottom about using UTF-8)

http://support.microsoft.com/kb/893663/en-us (mentions some of the
problems with codepage/symbol sets differences in ASP)

http://czyborra.com/charsets/iso8859.html (reference on 8859,
include implications as to the problems with Turkish)

http://en.wikipedia.org/wiki/Wikipedia:Turkish_characters (ISO8859-1
problems with Turkish in Wiki)
 
Back
Top