Page 1 of 1

[patch_done] utf8+D_XE+win 32/64 + testing-egonhugeist 1132

Posted: 06.04.2012, 08:19
by rakosmar
in myslq 5.x - 5.5.20 -utf8_czech_ci
varchar is ok,
but mediumtext or longtext after post delete character with diacritic
- attachment

char witch wedge are ok (ěščřžý)

Posted: 06.04.2012, 13:50
by EgonHugeist
rakosmar,

this is a known bug. He's still reported and included in our test-suites since a long time. I must admit that i was out of time to find out what's going wrong.

Some thoughts concerning this bug:

Zeos compares all fields from a row between Cached-ResultSets and the DbcResultSet to figure out if a update has to be done. Then Zeos builds a update statement which normaly includes all changed fields. It seem's for me that exacly only all kind of blob fields (AnsiText(TMemo), Unicode-Text(TWideMemo) and binary) where ignored on collection the field-informations. It is possible that this behavior is wanted because such updates are very slow on the server-side. On the other hand it's realy a bug if only blobs are changed and no Key-fields are aviable...

Eventually one hint concerning a possible workaround: Is it possible that your table definition has no primarykey or a unique index? What happens if you've such one?

Or can you help us to find out whats going wrong?

best regards,

EgonHugeist

Posted: 25.04.2012, 22:48
by mdaems
It may be helpfull to add a TZSQLMonitor to your project to find out what query is sent to the server for doing the update. Are the right conditions used, ...
The reason may also be that a BLOB field is used in a where condition that isn't encoded exactly the same as the original value.

Mark

Posted: 02.05.2012, 18:27
by EgonHugeist
mdaems,

the fields where compared right and this bug doesn't belong to a wrong encoding. Siply the blob-fields are exclude on building the "where-clause". IF his table had a PrimaryKey or an unique index, then everything is fine, i promisse.

Test849723 or Test815852. One of them points to this issue.

Michael

Posted: 05.05.2012, 21:38
by EgonHugeist
Bug fixed Rev. 1237