Hi,

I don't get you, can you please provide more information. 
in my table view all looks good.

Bye Marc

.

Created attachment 5186 [details]
memo field display bug in dbase file in OOo644m1

THe problem actually appears to be with memo fields. I 've just
checked in another dbase file and the same problem exists. Normal text
fields, say of 25 or 30 characters in length are displayed correctly.
Memo fields containing longer lengths of text are displayed as
Hex.This does not occur in 643c.

I'm attaching a snaphsot file so that you can see the problem for
yourself.

TIA,

Alex

Just tested with stable beta 1.1, same problem. It happens with fields
that OOo interprets as MEMO LONGVARCHAR.

Can anyone confirm ?

Alex

Alex, I suspect it may have to do with the data you're using. I cannot
reproduce the problem with the 644, neither with a table created in
1.0.1 not in 644 itself.
So if your data isn't too confidential :) you might consider attaching
the files here (both the .dbf and .dbt, and zipped, please), perhaps
stripped down do some record or so.

An interesting question would be where you created the table ...

Hi,

Unfortunately, this is an IP database that contains confidential
information, so I can't send it to you. I can tell you though that I
created it originally with StarOffice 5.2.

If the data is at fault, why does everything show up OK in 1.0.1 and
1.0.2 ? It's only with the switch to the 1.1 branch (643, 644 and 1.1
beta) that I've started having this problem. I've been using the
database (and another one with the same problem) for over 2 years
without problems, and now it suddenly doesn't show correctly in the
latest developer version.

Looks like I'm stuck with 1.0 :-(

Alex

> Unfortunately, this is an IP database that contains confidential
> information, so I can't send it to you.

I feared that :(
No chance that you can strip it down to one record only, where only
the memo field contains some (dummy) data? (in case you're going to do
this, don't forget to reorganize the table in SO 5.2 to remove the
deleted records, or copy it into a fresh table in OOo 1.0.1 to ensure
all deleted records are really gone.)

If there is no such chance: can you reproduce it with other data
(perhaps also created in SO 5.2, and being similar, e.g. with respect
to data length and table structure or such)?

> If the data is at fault

No, I don't think that your data is at fault, but I do suppose it has
something special about it which triggers the bug in OOo - it
definately _is_ a bug, because you say it works perfect in older versions.

> Looks like I'm stuck with 1.0 :-(

No, please let's try to reproduce this - it sounds way too bad to
simply ignore it!

I don't have StarOffice 5.2 installed anymore, so I won't be able to
copy it from there. I've just checked in my latest download/install of
stable beta 1.1, and the problem's still there :-((

I could probably strip it down - let me look into it and get back to
you. Do you need the dbt and the dbf or just the dbt ?

Alex.

> I don't have StarOffice 5.2 installed anymore, so I won't be able to
> copy it from there

:(

> I could probably strip it down - let me look into it and get back to
> you. Do you need the dbt and the dbf or just the dbt ?

Both, because the dbt contains the memo content, while the dbf only
contains the reference to the memo.

You should probably create a new, empty table and only copy one record
to it. This way, you ensure that really no other content is left (when
deleting records in dBase, they are normally only marked as deleted,
until you reorganize, which is not possible in OOo anymore). And you
should probably do this in a version where the display was still okay.

Thanks.

I could reproduce it

Great. Thanks for that confirmation Ocke. I'm  copying the table
structure now to a new test dbase in 1.0.2, and I'll copy some
non-confidential data into it, and try accessing it from beta 1.1. If
the problem shows up, I'll send up the files to IZ as attachments to
this bug.

On a side note, I tried opening the dbt file in Gedit, and it was
refused stating that the file contained some UTF8 characters that
weren't readable. Just a hunch : has the UTF8 implementation changed
from 1.0 to 1.1 ?

Alex

Copying the data structure to a testdb in 1.0.2, and a single record
from the db didn't cause any display error in 1.1, so the display
error must come from the fact that the dbase was originally created in
StarOffice 5.2. By the way, I noticed that when I copied the table
structure in 1.0.2, it set my memo field lengths to a default of 16,
whereas in the preexisting dbase these fields were set to 0, so I did
the same.

I seem to recall that there was a problem with memo field display in
an earlier version of OOo that led to the workaround of defining memo
fields with a length of 0. Any incidence here perhaps on my current
problem ?

Since I don't have 5.2 anymore, I won't be able to upload a subset of
the information. :-(


Alex

Created attachment 5307 [details]
sample database

confirming. The attachment
http://www.openoffice.org/issues/showattachment.cgi?attach_id=5307
contains a small sample table created in SO 5.2, and it's memo column
is displayed as Hex in SRX644m7.

Alex, thanks for pointing this out!

Fixed in srx644_dba04

If you want to rebuild the dbase driver, you
dba/connectivity/source/drivers/dbase/DNoException.cxx

Best regards,

Ocke

Please verify. Thx.

Ocke,

I won't be able to verify, since I don't have the build environment
(I'm only using binaries) and as far as I know the latest binary
download available on the mirrors doesn't yet contain the fix.

Alex.

Alex, Ocke assigned this one to MSC, and I think he also addressed
Marc, and not you :). Thanks for feeling addressed, anyway :)

.

.

verified in srx 644 m11, but not public yet.

Hi

this issue is fixed in OOo 1.1 Beta2 which is available at
http://www.openoffice.org/dev_docs/source/1.1beta2/.

I close this bug now.

Bye Marc

*** Issue 13449 has been marked as a duplicate of this issue. ***

change subcomponent to 'none'