Apache OpenOffice (AOO) Bugzilla – Issue 6118
Fields in db forms are sometimes not updated
Last modified: 2006-05-31 14:29:06 UTC
I create a .dbf database. Then, with autopilot, I create a form to display its contents. I open the form. I scroll the records of the database. Some of the data fields are not correctly updated. Passing from record n to record n+1 some fields continue to display the data of record n instead of inserting the data of record n+1. This happens often when the concerned field of record n+1 is empty. This is a rather nasty bug as it renders forms (almost) useless. I am ready to send the files if someone asks for. Many thanks for you work on ooo.
Emanuele, files would indeed help. I do not know of such a behaviour, I assume there is something special about your files. If they do not contain sensitive data or such, do you mind attaching them to this issue here? Thanks Frank
Emanuele, can you please give some more info which could help to reproduce this? table structure, data in the tables, and such? Or the files which you are using? Thanks Frank
Created attachment 3189 [details] This is the data I use.
Created attachment 3190 [details] this is the form I use, created with the wizard
This is what I done: 1) I registered the data source, type dbase, IBMPC 850 DOS, tables indirizzi 2) I created the attached form with the form wizard 3) When in the form, if you press "next record" (>) button and "previous record" (<) button several times you will notice that the field N1 is seldom not updated and remains "Consorzio Gorgovovo" instead of showing "Consorzio Intercomunale Servizi". This behaviour exists also with ODBC data sources. I think it's clear that such a bug render forms unusable for a professional use!
(wrote the following before your most recent comment. Will try what you described next.) Hmm. Emanuele, I cannot reproduce this with the files you gave (thanks) - I created a data source named indirizzi pointing to the location of the dBase file, and opened the form. Traveling through it seems to work perfectly - I always see the proper data. I tested this in OOo 1.0 and 1.0.1 - successfully. Do you have any more information? Do you do something different? The only strange thing I noticed is that the sxw document you attached did contain data in all controls except the first one. This means that at the very moment the document was saved, the controls where not (properly) bound to a table field. [1] But this would mean that all these controls did not work (mean not change at all when traveling) for you. Did they? Frank [1] In general, control data is saved in the file if and only if the control is not properly bound - this is because if it is bound, the data is considered to be "saved" in ther bound field.
Indeed! I reproduced it in OOo 1.0. Ouch! Very bad! (And very strange.) Have to try other versions.
reproduced in OOo 1.0.1, too. In the most recent inhouse builds, I even had a situation where simple traveling through the records changed the data - on record 2, the data of record 3 was displayed, and when traveling back to record 1, the data of record 3 was _written_ into record 2. This is indeed severe! I change the OS to "all" as I reproduced it on windows, too.
Emanuele, can you please verify or falsify that the problem vanishes when the form document is reloaded? I was able to reproduce it with newly created forms, but not after closing and re-opening, or simply reloading it.
accepting
Ocke, please look at this. It seems that the control does not get a propertyChanged notification for the column they are listening at.
3 bugs: * One is in the graphics system layer, in VCL, this is submitted as issue 8399 * One is covered by issue 2817 * One is fixed by Ocke in the DBA code and has good chances for OOo 1.0.2
Emanuele, as a workaround, you may want to unlimit the text length for the controls. The auto pilot creates text controls which's input length is limited to 30 characters, no matter of what the column length of the underlying table is (this is covered by issue 6235). If you unlimit the text length, the effect will perhaps not completely vanish, but at least happen much less.
I confirm. Reloading the document (the day after, probably sleeping on it helps? ;-) makes the bug disappear. [OT] Thanks a lot for your daily work on OOo, it's really wonderful. Our business depends on you!
Fixed in next version.
close
change subcomponent to 'none'