error 21005 with odbc connection

hi, i'm trying to retrieve rows that contains accidentely characters (\\0207 in octal) in a column char. my odbc application fails with error -21005. could it be possible to add this character in the gls files ? i have try several connect version without sucess. thanks

vomaringo@yahoo.com wrote: > hi, > i'm trying to retrieve rows that contains accidentely characters > (\\0207 in octal) in a column char. This looks like a currently frequent problem with some customers, that has very little to do with accident. It results from permissive behavior in the product and in the configuration we establish. I don't mean to criticize you (this happen to me also), but instead I want to warn you that if you don't act this will happen again... > my odbc application fails with error -21005. could it be possible to > add this character in the gls files ? In theory yes, but you'd need the GLS kit which I don't think is available to customers. It's probably not the best solution anyway > i have try several connect version without sucess. > thanks If you connect with DB_LOCALE=en_us.cp1252 and CLIENT_LOCALE=en_us.cp1252 you'll probably be able to connect and fix the character. This will work in 7.31, some versions of 9.4 and earlier versions (up to FC3 maybe...) of v10. If you receive an error indicating LOCALE mismatch you can temporarily set your engine to be permissive. Check the following URL for further explanation and to learn how to configure your environment to accept connections with wrong LOCALE. http://www.ibm.com/developerworks/blogs/page/gbowerman?entry=trouble_with_locales This situation was probably caused by having DB_LOCALE=CLIENT_LOCALE=en_us.cp1252 in your windows client configuration. Thisindicates that no conversion is done (client and database locales are the same). As such, CP1252 characters (\\0207 is decimal 135 if I got the conversion correctly, which is valid in CP1252, but does not exist in 8859-1), were inserted "as-is" in the database. With recent versions of the CSDK (I'd bet you upgraded them...), it looks for the DB_LOCALE from the database and uses it. The problem arises when it fetches a character which shouldn't be there... NOTES: I'm assuming you DB_LOCALE is en_us.819 == en_us.8859-1 (the default) I'd like to write a blog article about this, because I feel more and more customers are hitting situations like this... But time is short... -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...