Charset UNICODE_FSS problem [SOLVED]
Charset UNICODE_FSS problem [SOLVED]
Greetings!
My application was in Delphi 2007 using DbxIda 2.40. Worked fine. Was upgraded to Delphi 2010 and now uses DbxIda 2.50.0.23.
When I log in and my application retrieve some data from the DB, I receive the error:
"COLLATION PT_BR for CHARACTER SET UNICODE_FSS is not defined'
I used previously the character set ISO8859_1, wich contains this collate, "PT_BR", very useful here in Brazil. My database was designed using this character set, and I still want to use it.
In the TSQLConnection, on the Devart driver options, under "Charset" I put iso8859_1 and nothing happens, the connection is still made using the UNICODE_FSS charset. Tried to put it in the TSQLConnection's parameters, with no luck. Tried to set iso8859_1 by code on the Delphi's BeforeConnect method, with no success.
The option "UseUnicode" of the driver is not set, I've verified it.
What I'm doing wrong? I need the driver to connect using charset "ISO8859_1" no matter what, not "UNICODE_FSS", and I can't.
Thanks in advance!
My application was in Delphi 2007 using DbxIda 2.40. Worked fine. Was upgraded to Delphi 2010 and now uses DbxIda 2.50.0.23.
When I log in and my application retrieve some data from the DB, I receive the error:
"COLLATION PT_BR for CHARACTER SET UNICODE_FSS is not defined'
I used previously the character set ISO8859_1, wich contains this collate, "PT_BR", very useful here in Brazil. My database was designed using this character set, and I still want to use it.
In the TSQLConnection, on the Devart driver options, under "Charset" I put iso8859_1 and nothing happens, the connection is still made using the UNICODE_FSS charset. Tried to put it in the TSQLConnection's parameters, with no luck. Tried to set iso8859_1 by code on the Delphi's BeforeConnect method, with no success.
The option "UseUnicode" of the driver is not set, I've verified it.
What I'm doing wrong? I need the driver to connect using charset "ISO8859_1" no matter what, not "UNICODE_FSS", and I can't.
Thanks in advance!
Last edited by trindade on Mon 02 Aug 2010 18:02, edited 1 time in total.
Updating...
If I use the native Delphi 2010 Firebird driver, the TSQLConnection respects the "Charset" setting and effectively connects using charset "ISO8859_1", avoiding me the error mentioned above.
The SQL that causes the error, just in case, is:
SELECT * FROM usuarios WHERE usuario = 'admin' COLLATE PT_BR
All the character fields in my database and the database's charset are ISO8859_1.
If I use the native Delphi 2010 Firebird driver, the TSQLConnection respects the "Charset" setting and effectively connects using charset "ISO8859_1", avoiding me the error mentioned above.
The SQL that causes the error, just in case, is:
SELECT * FROM usuarios WHERE usuario = 'admin' COLLATE PT_BR
All the character fields in my database and the database's charset are ISO8859_1.
In Delphi 2010 the UseUnicode connection parameter is set to True by default.
To solve the problem set the proper parameter of TSQLConnection to True, like this:
To solve the problem set the proper parameter of TSQLConnection to True, like this:
Code: Select all
SQLConnection.Params.Values['UseUnicode'] := 'False';
Nope. Thanks, but I've tested and I've got same error. Using "True" or "False".Dimon wrote:In Delphi 2010 the UseUnicode connection parameter is set to True by default.
To solve the problem set the proper parameter of TSQLConnection to True, like this:Code: Select all
SQLConnection.Params.Values['UseUnicode'] := 'False';
I've read in the documentation, and read when UseUnicode is true, DbxIde forces the use of the charset UNICODE_FSS on the connection. That's precisely what I'm NOT needing. I've told on my previous post that UseUnicode is not set, precisely to avoid DbxIda to connect using UNICODE_FSS charset.
I just wanna connect using charset ISO8859_1 instead of UNICODE_FSS. With Delphi's native Firebird driver it works, with DbxIda not.
My suggestion is: the Charset property in TSQLConnection must have precedence over UseUnicode property. The programmer must have the responsibility of setting it properly, unless it's left blank. This should give the most flexibility for international apps.
In United States charset isn't important, because English words are simple, but on the rest of the world, where people use more complex language, with special characters, it's critical.
I'm still stuck here. Any other suggestions?
To reproduce the problem, you'll need a database with iso8859_1 fields and collate pt_br. Is just to apply the SQL query that I exemplified on my second post and the error will pop out.Dimon wrote:I can not reproduce the problem.
Please, try to compose a small sample to demonstrate the problem and send it to dmitryg*devart*com, including script to create database objects.
But, most of all, you must have to verify under what charset the connection has been made. This is crucial, because in this resides my whole problem.
But OK, I'll gather the needed data and will send it to the e-mail specified. Will post the solution here later.
Thanks for the attention!
OK, I've solved the problem.
Writing an application from scratch to demonstrate the problem to you, I discovered that my new application gave no errors. So, must not be DbxIda's fault.
Upon further investigation, I've discovered that in my existing app, I must specify the "collate" so special characters must be considered correctly on search queries. In my new app, it's irrelevant to specify the "collate" setting, all results are the same. Why this behavior, I've not surely identified yet.
But, at the end, the problem was my application loads DB settings from an INI file, and an obsolete setting was "ServerCharSet" to specify the DB charset, and the updated setting is "CharSet". Even specifying this new setting on TSQLConnection connection and in code, upon loading of INI file, this updated setting was overriden, the charset specified was not set and I got the error "COLATION PT_BR NOT DEFINED FOR CHARSET UNICODE_FSS". I've redesigned the INI parameter reading routine, and now appears that the charset is defined properly, since I still use "collate" and I've got this error no more.
Thanks for the help and attention, now development must go on.
Writing an application from scratch to demonstrate the problem to you, I discovered that my new application gave no errors. So, must not be DbxIda's fault.
Upon further investigation, I've discovered that in my existing app, I must specify the "collate" so special characters must be considered correctly on search queries. In my new app, it's irrelevant to specify the "collate" setting, all results are the same. Why this behavior, I've not surely identified yet.
But, at the end, the problem was my application loads DB settings from an INI file, and an obsolete setting was "ServerCharSet" to specify the DB charset, and the updated setting is "CharSet". Even specifying this new setting on TSQLConnection connection and in code, upon loading of INI file, this updated setting was overriden, the charset specified was not set and I got the error "COLATION PT_BR NOT DEFINED FOR CHARSET UNICODE_FSS". I've redesigned the INI parameter reading routine, and now appears that the charset is defined properly, since I still use "collate" and I've got this error no more.
Thanks for the help and attention, now development must go on.