|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
ADO .NET 1.1 issue with stored proc params missing but only if culture is Turkish.(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 On Jan 30, 9:33 pm, gcxmuirh***@gmail.com wrote:
Show quote > I have an application that is localized into a number of cultures I am looking into what may be a related problem so the following may> (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 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) |
|||||||||||||||||||||||