[yunqa.de] Re: D2007-D2010: corrupted text in database

  • From: Петров Дмитрий Юрьевич <petrov@xxxxxxxxxxxxxxxxxx>
  • To: Delphi Inspiration <yunqa@xxxxxxxxxxxxx>
  • Date: Wed, 27 Jan 2010 20:07:47 +0200

Thanks for your patience :)

I have a last question. Will it be correct if I shall try to convert
database in runtime by reading a row with Stmt.Column_Text() and
updating with
 "UPDATE ... Where rowid = ..."
 .Execute16(UnicodeString);


>>Thanks for the tip. Using UnicodeStrings and Prepare16 function solves
>>the problem, database becomes readable in both Delphi versions.

> Good!

>>The problem is that a do not write a new program, I just want to
>>migrate from Delphi 2007 to Delphi 2010. There are already hundreds of
>>customers who use my program compiled in D2007 and they already have a
>>database which uses ".Prepare" and "Column_Str()" not ".Prepare16" and
>>"Column_Str16()". 

> If you did not use the ...16() versions of DISQLite3 methods and
> did not convert your Cyrillic characters to UTF-8, all your D2007
> databases contain text in an "invalid" character set. I placed
> "invalid" in quotation marks because, technically speaking,
> DISQLite3 happily stores and retrieves any text in any character set
> you pass to it. This is why your application appears to be working fine.

> Internally, however, DISQLite3 relies on correct text encodings for
> built-in SQL functions like LENGTH(), REPLACE, SUBSTR(), and others.
> I suppose you do not use those at the moment. But if you would use
> them with text in Cyrillic character set, they will not work
> correctly, even with your D2007 application.

>>While everything is good under D2007 I still do not
>>understand how can I read data from such old database in D2010...
>>The only way I managed to read it is by using Stmt.Column_Text().

> Correct. The Stmt.Column_Text() returns whatever you have put into
> a text field with no changes. You could use it with D2010, but only
> if also handle D2010's automatic, behind the scenes character
> conversionl. Still, this would still leave you with the "invalid"
> character set problem on the SQL level and is therefore _not_ recommended.

> Instead, I suggest to fix your "invalid" database files and convert
> them to proper UTF-8 encoded ones.

> SQLiteSpy (http://www.yunqa.de) can help with this: Open a database
> file, choose Menu -> Execute -> Text to Unicode Conversion..., check
> all tables and columens you want to convert, choose the source
> character set (probably 1251 ANSI Cyrillic) and convert. Browse the
> database to verify the conversion, then COMMIT to save the changes
> or otherwise ROLLBACK and try another character set.

> Ralf 

> _______________________________________________
> Delphi Inspiration mailing list
> yunqa@xxxxxxxxxxxxx
> //www.freelists.org/list/yunqa




> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4809 (20100127) __________

> The message was checked by ESET NOD32 Antivirus.

> http://www.esetnod32.ru





-- 
Ñ óâàæåíèåì,
 ??????                          mailto:petrov@xxxxxxxxxxxxxxxxxx

_______________________________________________
Delphi Inspiration mailing list
yunqa@xxxxxxxxxxxxx
//www.freelists.org/list/yunqa



Other related posts: