Using UNICODE versions over several EDB releases up to date, and
various Delphi versions up to Seattle.

I use a CLOB field to store a TStringList, typically a modest number of
short (max 30 chars) strings (UTF-16).

Mostly it works as expected but sometimes reading the CLOB back into
the TStringList returns 'garbage', looking rather oriental.

I remembered seeing posts about this some time ago, maybe when the CLOB
was 'empty', but my searches did not find a thread matching my
experience.

It may be when I save a set of empty strings, ie a series of CRLFs, but
it is very random.  Grrr.
Perhaps more prevalent after a database Restore.

Does anyone have any ideas .. or have you also seen this?

Malcolm wrote:

> Mostly it works as expected but sometimes reading the CLOB back into
> the TStringList returns 'garbage', looking rather oriental.

Save the actual CLOB data to disk using the EDB tools, and then look at
it in a hex editor. Sounds like the text is being mis-interpreted. Key
then is whether it reads out badly, or is being written badly.

--

Matthew Jones

Malcolm,

<< Mostly it works as expected but sometimes reading the CLOB back into the TStringList returns 'garbage', looking rather oriental. >>

I assume that you're manually moving the data back and forth from the TStringList instance to the CLOB ?

Can you reproduce this behavior ?  Also, are you making sure that your TStringList instance is using the desired string encoding at all times ?

Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim

Perhaps I am taking too much for granted.  

The column type is: CLOB COLLATE "UNI"

At database open I do:
  theStringList.Assign(thetable.FieldByName('Memo');

After any edit, or before a database.close I do:
  thetable.FieldByName('Memo').Assign(theStringList);

The list can have empty strings or even be completely empty.

I assumed(!) that as I am using TStrings in the TStringList and the
CLOB is "UNI" the encoding was a 'given'.
Is that not so?  
Or am I just doing it completely the wrong way?  

I would do as Matthew suggests to debug the contents but I never know
when it will happen .. and when it does it is usually when I am in the
field without the utilties to hand.

Malcolm

Malcolm,

Sorry about the delay in responding.

<< The column type is: CLOB COLLATE "UNI"

At database open I do:
  theStringList.Assign(thetable.FieldByName('Memo');

After any edit, or before a database.close I do:
  thetable.FieldByName('Memo').Assign(theStringList);

The list can have empty strings or even be completely empty. >>

Can you reproduce what you're seeing reliably ?  I just tried the following in XE6, and it works fine:

procedure TForm21.Button1Click(Sender: TObject);
begin
  TempStrings:=TStringList.Create;
  TempStrings.Clear;
  TempStrings.Add('Test 1');
  TempStrings.Add('Test 2');
  with EDBTable1 do
     begin
     Append;
     FieldByName('Text').Assign(TempStrings);
     Post;
     end;
end;

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Can you reproduce what you're seeing reliably ?  I just tried the
> following in XE6, and it works fine:
....

No, and that's the trouble.
Mostly it works just fine.
I will need to pay more attention when I do see it.  
I think it mostly, yet rarely, happens following a restore.  I was
wondering if a mostly empty CLOB, perhaps containing just a few empty
strings might suffer after being compressed into a backup then expanded
during a restore and wind up being interpreted incorrectly for some
reason.

Just for background info:  The application is for sports events, and
major events tend to be saved in individual backup files.  Users often
send them to me for merging into my results database or to provide
example data, or for support.  So backup and restore operations are
common (as it will be for you) - but the problem is rare.

OK, it's not a known issue.  I will just try to keep any eye out for
clues.   Probably somehing I am getting wrong.  

Malcolm,

<< I think it mostly, yet rarely, happens following a restore.  I was wondering if a mostly empty CLOB, perhaps containing just a few empty strings might suffer after being compressed into a backup then expanded during a restore and wind up being interpreted incorrectly for some reason. >>

Backups/restores in EDB are "raw" operations, there is no interpretation going on.  So, I doubt if there's an issue there.

<< Just for background info:  The application is for sports events, and major events tend to be saved in individual backup files.  Users often send them to me for merging into my results database or to provide example data, or for support.  So backup and restore operations are common (as it will be for you) - but the problem is rare. >>

Do all of your customers use Unicode databases ?

Also, is it possible that they're mixing up the .EDBBlb files in some way ?

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Do all of your customers use Unicode databases ?
>
> Also, is it possible that they're mixing up the .EDBBlb files in some
> way ?
>

I only supply UNICODE versions.  
The only exception to UNICODE is the need to use some ASCII when
communicating with serial coms hardware and that does not touch the
database.
The problem does not apear to be linked to locale.

I don't have any reason to think users are at all likely to touch the
..EDBBlb files.  It would only be a result of Restore-ing a database and
I assume EDB handles that - any security/permission issues arising from
that would presumably raise an error of some type.

If I discover anything specific I will come back, otherwise I think you
can ignore this.

Malcolm

Malcolm,

<< If I discover anything specific I will come back, otherwise I think you can ignore this. >>

Thanks.  If you find out anything new, feel free to report back here and we'll take it from there.

Tim Young
Elevate Software
www.elevatesoft.com

Gottit .. sort of ..

It bit me today (instead of a user).
I used the CLOB Editor to export the garbage from the EDB Manager into
a file then opened it with a Hex Editor.
Yay!  It showed a BOM (FF FE) followed by plain ANSI text.
But it should have been UNICODE .. unless one of the two editors
transformed it during the export or file open.
So now I know it is an encoding problem - if not exactly why it is
happening.

Definite progress.