Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 05/11/2016 04:38 PM, Michael Van Canneyt wrote: Where is the string-type for string-buffers gone? There never was one, this would break in 2.6.4 too. Right. But -> http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support -Michael

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 2016-05-11 21:58, Mattias Gaertner wrote: >> > They made the changes to take advantage of the new >> > functionality in FPC 3.0, because the end result is much simpler code >> > both in the LCL and in user programs. > > Yes, simpler and more powerful. For example FPC now supports full UTF-8 >

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On Wed, 11 May 2016 22:33:13 +0200 Jonas Maebe wrote: > Graeme Geldenhuys wrote: > > On 2016-05-11 18:58, Michael Van Canneyt wrote: > >> > For 99,99% of cases, no changes to your code are required. > >> > If it worked in 2.6.4, it will work in 3.0.0 > > > > Just

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On Wed, May 11, 2016 22:08, Graeme Geldenhuys wrote: > On 2016-05-11 18:58, Michael Van Canneyt wrote: >> For 99,99% of cases, no changes to your code are required. >> If it worked in 2.6.4, it will work in 3.0.0 > > Just curious, so why was there so many changes required for LCL, and a > whole

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

Graeme Geldenhuys wrote: On 2016-05-11 18:58, Michael Van Canneyt wrote: > For 99,99% of cases, no changes to your code are required. > If it worked in 2.6.4, it will work in 3.0.0 Just curious, so why was there so many changes required for LCL, and a whole wiki page of its own to explain

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 2016-05-11 18:58, Michael Van Canneyt wrote: > For 99,99% of cases, no changes to your code are required. > If it worked in 2.6.4, it will work in 3.0.0 Just curious, so why was there so many changes required for LCL, and a whole wiki page of its own to explain it? Regards, Graeme --

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

Am 11.05.2016 19:35 schrieb "Santiago A." : > Something about codpages needs a second thought. > > a) There shouldn't be automatic conversion at all. > b) The codepage of a string shouldn't change when you assign a string with another codepage, just rise an error. > c)

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On Wed, 11 May 2016, Santiago A. wrote: El 11/05/2016 a las 16:38, Michael Van Canneyt escribió: FPC 3.0 adds unsafe auto-conversions Why do you think it is unsafe ? I have an answer for this. In short: Different codepage strings and raw strings should be considered different

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

El 11/05/2016 a las 16:38, Michael Van Canneyt escribió: > >> FPC 3.0 adds unsafe auto-conversions > > Why do you think it is unsafe ? > I have an answer for this. In short: Different codepage strings and raw strings should be considered different incompatible types. Pascal is a hardtyped

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

Andreas Dorn wrote on Wed, 11 May 2016: All in all Graeme is right. FPC looks pretty much broken to me, too. For my projects I pulled the emergency-break on anything FPC.   The most serious flaws for me of FPC 3.0 are: - assuming that it's possible to assign an encoding to every string - using

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On Wed, 11 May 2016, Andreas Dorn wrote: All in all Graeme is right. FPC looks pretty much broken to me, too. For my projects I pulled the emergency-break on anything FPC.   The most serious flaws for me of FPC 3.0 are: - assuming that it's possible to assign an encoding to every string -

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

All in all Graeme is right. FPC looks pretty much broken to me, too. For my projects I pulled the emergency-break on anything FPC.   The most serious flaws for me of FPC 3.0 are: - assuming that it's possible to assign an encoding to every string - using an (unsafe) guess about the encoding

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

Graeme Geldenhuys wrote on Wed, 11 May 2016: My test program under FPC 2.6.4 doesn't give problems. It's when that same program is compiled under FPC 3.0.0 that it does. All due to String (and thus AnsiString) changing its encoding based on the running environment. In FPC 2.6.x, if you use a

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On Wed, 11 May 2016, Jonas Maebe wrote: Michael Van Canneyt wrote on Wed, 11 May 2016: On Wed, 11 May 2016, Graeme Geldenhuys wrote: If anybody has the time, I would really like to learn how. Using FPC 3.x. Running the example program in a Latin-1 [console] environment and still get the

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 2016-05-11 14:14, Jonas Maebe wrote: > compared to FPC 2.6.x due to automatic conversions in the RTL and FCL. > When it is clear that is not true, you are now saying that the > behaviour of FPC 3.0 is different to FPC 2.6.x if you compile > different code with each one. My test program

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

Michael Van Canneyt wrote on Wed, 11 May 2016: On Wed, 11 May 2016, Graeme Geldenhuys wrote: If anybody has the time, I would really like to learn how. Using FPC 3.x. Running the example program in a Latin-1 [console] environment and still get the correct data stored in the output.data file.

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

Graeme Geldenhuys wrote on Wed, 11 May 2016: On 2016-05-11 13:27, Jonas Maebe wrote: If you change the string to unicodestring (since FPC 2.6.4 does not know {$modeswitch unicodestring}), you should get the same results in FPC 2.6.4 and FPC 3.x No, because FPC 2.6.4 doesn't do automatic

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On Wed, 11 May 2016, Graeme Geldenhuys wrote: On 2016-05-11 13:37, Michael Van Canneyt wrote: It would not help if we did this: the data would be wrong in the TDataset buffers, and the result would be worse. I didn't mean literally search and replace - that would simply be too easy. ;-)

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 2016-05-11 13:27, Jonas Maebe wrote: > If you change the string to unicodestring (since > FPC 2.6.4 does not know {$modeswitch unicodestring}), you should get > the same results in FPC 2.6.4 and FPC 3.x No, because FPC 2.6.4 doesn't do automatic encoding conversions. I would first have to

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 2016-05-11 13:37, Michael Van Canneyt wrote: > > It would not help if we did this: the data would be wrong in the TDataset > buffers, and the result would be worse. I didn't mean literally search and replace - that would simply be too easy. ;-) Some work and testing would be required,

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 2016-05-11 12:03, Graeme Geldenhuys wrote: > I wrote a small > test program that reads data from a Firebird database where the database > and field charset is set to UTF8. For those that want to try the sample application, a backup of the database (3.7MB in size) can be found at:

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On Wed, 11 May 2016, Graeme Geldenhuys wrote: On 2016-05-11 13:07, Michael Van Canneyt wrote: But what does your program prove ? See below... You're only proving that a conversion happens when you do s := fieldByName('somefield').asString; I'm proving that using the String type

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

That's because you have {$modeswitch unicodestring}, so string=unicodestring. This is answer to my question :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

I just double checked my results again. With u: String variable and compiled with FPC 3.0 and running in a Latin-1 environment, data is completely corrupted. It will be good to know where this happens. Because AFAIK fcl-db internaly uses AnsiString/String so assigning between them should

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

Graeme Geldenhuys wrote on Wed, 11 May 2016: On 2016-05-11 13:05, Jonas Maebe wrote: Your concern is with utf8string, not with string/ansistring. UTF8String is a AnsiString with utf-8 code page set. If you only use string/ansistring/unicodestring, then the behaviour of your program will be

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 2016-05-11 13:07, Michael Van Canneyt wrote: > > But what does your program prove ? See below... > You're only proving that a conversion happens when you do > s := fieldByName('somefield').asString; I'm proving that using the String type anywhere in the RTL and FCL is now terrible. If the

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 2016-05-11 13:05, Jonas Maebe wrote: > > Your concern is with utf8string, not with string/ansistring. UTF8String is a AnsiString with utf-8 code page set. If you > only use string/ansistring/unicodestring, then the behaviour of your > program will be identical with FPC 2.6.4 and 3.0. With

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On Wed, 11 May 2016, Graeme Geldenhuys wrote: Hi, Here is an example [proof if you will] of the problem. I wrote a small test program that reads data from a Firebird database where the database and field charset is set to UTF8. I compile the program, then run it. No recompiles between the

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 2016-05-11 12:03, Graeme Geldenhuys wrote: > Console output: > > [unicode_test]$ export LANG=en_US.UTF-8 > [unicode_test]$ ./unicodetest > 65001 > > [unicode_test]$ export LANG=en_US.ISO8859-1 > [unicode_test]$ ./unicodetest > 28591 Just to add, compiling that test program with FPC 2.6.4 I

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

Graeme Geldenhuys wrote on Wed, 11 May 2016: I'm honestly trying very hard to understand the string changes implemented in FPC 3.x, and the best way to use it going forward. In this example I tried everything I learned from the recent mailing list discussions. My concern with the usage of

[fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

Hi, Here is an example [proof if you will] of the problem. I wrote a small test program that reads data from a Firebird database where the database and field charset is set to UTF8. I compile the program, then run it. No recompiles between the two runs. The first run my system is set to have a