Issue 108299

Created attachment 67178 [details]
a broken odb

http://qa.openoffice.org/issue_handling/basic_rules.html#reproducibility

I fail to understand the problem. Opening the attached database in OOO 3.2 RC 2,
and looking into the definition of the contained table: All VARCHAR fields have
a formatting "@", i.e. a text format.

Please describe in detail what you do, what you expect to happen, and what
actually happens.

Also, if you seriously think this is a 3.2 show stopper, then raise this in
releases@openoffice.org. However, please be advices that in the current shape,
the bug will most likely not be accepted as stopper.

Created attachment 67212 [details]
pls find the wrong format-setting in this screencapture

Hmm, still cannot reproduce. Used OOo 3.2 RC 2, on Windows Server 2008. Both the
OOo UI and my locale settings were set to "German" (since I assume this is true
for your setup, too). Still, the columns have a text format, not a numeric format.

I'm somewhat clueless ...

@mhatheoo I've been unable to reproduce the problem here also - using XP, Win 7
and Ubuntu, sorry not Win 2008 server to test on.

-However-

I notice that the bug doc you attached is for a file named mhfilmase1.odb_0.odb.
Looks like you allowed OpenOffice.org to recover a Base file on startup -
personal experience has been that this is a very bad thing to do.

Next I notice that the screen shot is for he file mhfilmbase1.odb.

OK - to make this short. There have been times that thisre-naming has just
bitten me to the point that I was about to open an issue also, but finally
realized that was happening in reality - I was working with two different Base
files and didn't even realize it.

OO.o not just renames the file, it opens the renamed file and if you don't pay
attention you can make changes to this NEW file, close it and then try to use it
later only to open the ORIGINAL file ( or access it via the DataSource name,
still pointing to the ORIGINAL file). As an added bonus at this point there are
two entries ont he MRU menu and not real clear to the user which is which..

Anyway - just wanted to mention this, perhaps you are being plagued by the same
scenario that hs gotten me on, too many, occasions. 

> OO.o not just renames the file, it opens the renamed file and if you don't
> pay attention you can make changes to this NEW file, close it and then try
> to use it later only to open the ORIGINAL file ( or access it via the
> DataSource name, still pointing to the ORIGINAL file). As an added bonus at
> this point there are two entries ont he MRU menu and not real clear to the
> user which is which

The last of those two is now covered by issue 108366 (at least I hope that what
I described there is what you meant).

I couldn't, however, reproduce the first part, with Base writing to the wrong
(temporary) file. Can you try to reproduce this, and submit an issue (or tell
the details of how to reproduce it (outside this issue, preferrably))?

Thanks.

Yes, the screencapture came from the original database, the file I sent in is a
copy of one table only. 
It had not worked, but now it does.
I made a copy of that copy-odb, droped the equivalent file in the original-odb
and put the copy in - all fine. no clue why.

Maybe Andrew is right, and I sent in here a copy of a crashed/repaired odb.
having a crash refreshes content on re-opening, whereas the original odb
remained faulty. by that I still believe, that the problem does come from a
version-mix as said in the original post: raise the ODB in 3.1 and adding field
in version 3.2  caused the problems. 
However, there is a method to repair (copy to new - delete old - copy back)

I guess you should leave this issue open for some day, may be the problem had
happend with others too.

rgds
Martin

I missed to mention, that the screencapture seems to show a appropriate
test-method for this problem:

When a TEXTVAR-field a 0 as default-value, and when that is in grey only and the
...-changebutton can not be used, than the file is broken, not the content, but
the formatting.

Martin

@Martin - are you still experiencing this problem?

Thanks much

Hallo Grew
Not sure about that
-- All ODB-Files build/derived from DBASE- or CALC-files seems to be
broken(fieldlength 0)

-- All HSQL-based ODB seems to work (meaning: in one ODB tables are created in
Vers. 3.1. and 3.2), but I found an old example-ODB (db_sample_franco.odb),
where all fieldtypes double(Double) are detected with fieldlength 0 (should be 17)
My guess: not solved (in 3.2.RC5)
BTW: to me not reproducable anymore, as I dropped all 3.1 versions for that
reason (even knowing to other database-problems in 3.2)
 
Martin

Hello Drew

someone should raise the status of this - otherwise it will not make it into 3.2.1

(note: some of the serious things with ODB did note even made to the dependency-
or the issue-list - that must be changed!)

Martin

Created attachment 68982 [details]
Screenshot - actual version 3.2.1 - NOT WORKING - same glitch

Well, looking at the screen shot it appears you are using DEV300m_76. 

I checked the bug doc using OO.o 3.2.0 and DEV300m_76 w/ Ubuntu 10.04 and could 
not reproduce the problem. Then tried OOO320m_15 (3.2.1 code line), Vista and 
again could not reproduce it. I exercised this pretty well, table edits, query 
creation, form creation.

Over the next couple days will check this with calc/dbase sources.

I can not reproduce this. I set the issue to WORKSFORME and set the keyword
needhelp, maybe someone can provide a step-by-step description how to reproduce
this.

Bye Marc

Hey Marc

great to see that you started programming for Base too and want to be involved
in triage. However, it would be kind if you had shown what you ment by "I can
not reproduce this".

The issue is reopend due to the none-working 3.2.1 m15
You can make up your mind by looking into the attached ODB (and find the
problem) - or leave this issue just open for giving others the chance to have a
look. Thanks.

Martin 

Created attachment 68989 [details]
nonworking form - created with the wizard

well, that last attached file is broken - every text field displays the '0' for 
formatting and that results in the form wizard creating forms that misformat the 
data.

Can you tell me how to reproduce whatever it is you did?

hey Drew

please look at ther original post, that was the problem.
This file is not broken, it is the copy of the table that I made today, that
table where you got the screencapture on yesterday.
The new ODB of today was build only to give you something at hand for seftesting.

Martin

I was hoping you wouldn't say that - I tried, I copied the file, I copied the 
table, I did it with a couple of ODB, even used Calc as an intermediary - nothing 
going wrong with any of the files here - however I'm doing everything in English - 
I can try downloading the German language pack later today..maybe that's it.

> great to see that you started programming for Base too and want to be
> involved in triage.

Given that Marc has more years of Base QA experience than, for example, I have
in Base development (which are 11.5), I find this statement of yours quite ...
ignorant - and this is my careful wording.

> well, that last attached file is broken - every text field displays the '0'
> for formatting and that results in the form wizard creating forms that
> misformat the data.

Even when a "0" is displayed as format example in the table editor, this doesn't
meant the column is treated as numeric - if somebody says this, then he's
jumping to conclusions. "0" is just a unfortunate default as example
illustrating a text format, nothing more. Use the "..." button after the format
example box to see that indeed the column has a text format associated with it.


The bug I actually *do* see is the following:
Consider the field "mfpkuerzel" in the table in attached "copypersonen.odb"
file. In the table data view, you see that this field is empty in the first two
records, and contains a non-empty value in the third record.
In the contained form, this field is displayed using a text box, which displays
an empty string for the first two records, but "0" for the third record.
(using an English OOO320m14, on Windows Server 2008, with a German locale. Not
sure any of this matters, didn't try other combinations.)

That certainly is a bug. However - a) I am not sure if this is what the original
reporter meant and b) this bug appears to be existing in both 3.1.1 and 3.0.1,
so it can never be a stopper for 3.2.1.

> Even when a "0" is displayed as format example in the table editor, this
> doesn't meant the column is treated as numeric - if somebody says this,
> then he's jumping to conclusions.

I stand corrected: The field *does* have a numeric format, which explains the
"0" being displayed in the text box.

So, the main question is how the field did get this wrong format. One could add
code for determining such an pathological situation, and fixing it on the fly,
which would at least "repair" the corrupted documents. But the question remains
how they were produced ...

For the record: The answer to this question might control whether this is really
worth a 3.2.1 target. For instance, if only, say, a certain developer snapshot
has produced such documents, then 3.2.1 might not be justified. If it is
possible to create such corrupted documents with, say, a 3.2 release, then 3.2.1
might be justified.

@fs - yes, the way you describe the behavior is what I see here. My only problem 
is I can't figure out how to make another file with the same problem, so far.

@mhatheoo - I know you are frustrated, cause I know it is not working for you, but 
trust me everyone is trying to reproduce this and it isn't happening, so yeah we 
do need to try an find why your installation is doing this...and yes Marc is a big 
part of helping you on this, so I have agree with Frank the personal crack was out 
of line. (to be fair, I'm guilty of a few out of line cracks lately myself)

wow, lot of responds, decent, fair and straight forward to the solution.
Thats quite okay.


Back to work:
The file can easy be opend in 3.1.1 - I just gave it a try with the portable version


Martin

> The file can easy be opend in 3.1.1

Hmm. With "can be opened" - do you mean you can open it, and it displays the
proper strings in the form?

If so, I cannot confirm this, in my 3.1.1 (which is not the portable version),
the texts are still displayed as "0".

Created attachment 68993 [details]
SC from 3.1.1 - the way it should work in 3.2.1

Okay, so you actually mean the data is displayed properly in your 3.1.1. Strange
enough, I cannot say the same thing of my 3.1.1 here ... :-\

Seems another person had a 'glitch' also and now can't reproduce it:
http://www.openoffice.org/issues/show_bug.cgi?id=111014

Hey everybody

wouldn't you think it is due time to set this issue to "new" 

Martin  

I just gave it a try with the portable version 3.2.0
Everything is working fine.
I already guessed so, but now I am quite sure: someone at OOO is using the wrong
compiler.

Martin

for me, all is working as expected with OOO 321 RC1
so it might be closed

Martin

I have just upgraded openoffice 3.2.0 to 3.2.1 on Mac OSX 10.6.4. Since the
upgrade the data in a number of form fields is no longer visible. The data is
still present in the source table. On examination of the source table it appears
that the non-visible fields in the form are all those listed with a format code
of 0 in the format example field. If the lookup tab, marked ... next to the
format field, is pressed the default format is shown as @. However it is not
possible to transfer the @ symbol into the format field example section.
This seems to be a similar problem to that reported in this bug report. 

Below is part of a copy of a suggestion I posted on the OO community forum in
the Forms section. I apologise for adding this here as it does not refer to
3.2.1RC but the problem seems very similar and I could not find a 3.2.1 section.
Interestingly, the problem seems to be only with forms using tables created in
the last year. When I opened a form created more than a year ago, which may have
been from a previous version of OO it opened and displayed correctly without any
changes to the base table.

The work around is to first back up your database and then, in the table edit
change the field type from eg TEXT VARCHAR to TEXT VARCHAR IGNORE CASE. You will
see that this puts the @ character into the format field. Then change the field
type back to TEXT VARCHAR and save your changes. I would not recommend making
any changes to a field that is a key field as I am not sure that such a change
would be without adverse results.

This was tested on MACOS 10.6.4 and it also works in Windows 7. Unfortunately,
for family reasons, I do not have a current installation of my preferred OS, Linux.
Ian