Apache OpenOffice (AOO) Bugzilla – Issue 59784
Database Wizard: "Open an existing database file" should not silently ignore errors on non-ODB files
Last modified: 2013-08-07 15:45:41 UTC
When I do this: 1) start OpenOffice Base from the Start Menu, which runs the Database Wizard; 2) select "Open an existing database file"; and 3) use "Open" to select a DBF file (eg, DISTRIB.DBF), then I get a screen with the Forms icon highlighted. When I click on the "Tables" icon, I get a message box stating: "The connection to data source "DISTRIB" could not be established." It also speculates that this is a driver problem. The More button leads to an Error icon with gives "S1000" as the SQL Status. If I use File | Open to open a second DBF file -- I get the Import dBase Files box and then an OpenOffice Calc window with the data displayed. If I use File | Open on the first DBF file, I get the same error. If I use File | Close, the OpenOffice Base window closes. However, I can now open the original file (DISTRIB.DBF) by using File | Open from OpenOffice Calc. The point being, the file itself is a properly-formed dBase file, and the drivers involved are clearly able to read it. If I close all OpenOffice windows and double-click on DISTRIB.DBF, it is opened without any problems. (I did search using "dBase" but none of the issues found appeared to be reporting this same problem).
hi, That files with a uppercase DBF extension are not displayed is issue 59361. can you open the file if you rename the file to distrib.dbf ? If not please attach the dbf file to this issue. Bye Marc
1) Changing the extension to lower case has no effect on this behavior. 2) The problem: invoking OpenOffice Base from the Windows Start Menu and then opening a dBase file (*.DBF or *.dbf, it matters not) results in a "failed to connect" message as described previously. 3) The intriguing parts: a) after the first attempt, any /other/ dBase file (*.DBF in particular) opens successfully, as described previously. b) double-clicking on a dBase file (*.DBF in particular) opens it successfully, as described previously. I have attached a *.DBF file, in case you do not have one handy, but, really, given the above, and the fact that the /exact same file/ behaves as above (to test 3)a) you can duplicate the attached & rename the copy), do you really think this is a file problem? Here is a possibility I will suggest: I have disabled (that is, reset to "Manual" from "Automatic") many of the services infesting the typical Windows computer because they do nothing which I have need of. Is it possible, do you suppose, that when the protocol in 2) above is followed, Windows first reports failure because some service is not working and then starts it? Whereas, in case 3)b) (which works whether the protocol in 2) has been done or not, that is, whether this hypothetical service has started or not) Windows starts the service first and then the application? Or, if what you are using is not a Windows service, could it still be behaving similarly? In other words, perhaps OpenOffice needs to try again. Especially (referring to the original message) when the user re-opens the file (I suspect it is merely checking a flag in that case and not actually trying to connect again).
Well, I tried to attach a dBase file, but, as often happens, it proved to be too complicated for ordinary people to manage. In this case, I was required to specify a "mime type". I did not notice "dBase file" or "dbf" among the choice given. Would you care to suggest what the "mime type" of a dBase file might be? Oh, and I tried "the protocol in 2)" (see message that claims a dBase file has been attached) with the entire file name in lower case and it makes no difference at all.
The real problem here is that "Open an existing database file", when you choose a dbf file via this item, really opens the DBF file as if it is a database. The "Open an existing ..." feature in the database wizard is intended to open ODB files, nothing else. Obviously, it silently assumes for *every* file that it is an ODB file. This then explains everything: > 3) use "Open" to select a DBF file (eg, DISTRIB.DBF), then > I get a screen with the Forms icon highlighted. This is the initial error - there should be an error message in the wizard saying "this is no database document". > When I click on the "Tables" icon, I get a message box stating: > "The connection to data source "DISTRIB" could not be established." This is because the DBF file could not be read as a ODB file. You can verify this by looking at Edit|Database|Properties, which shows complete nonsense. > If I use File | Open to open a second DBF file -- I get the Import dBase Files > box and then an OpenOffice Calc window with the data displayed. This works since it has nothing to do with the first file, and is opened by "regular" means, i.e. the File-Open dialog. > If I use File | Open on the first DBF file, I get the same error. This is because the file is not opened, again. Instead, OOo notices that the file is still open (though improperly opened), and only switches to the window where it is open. > If I use File | Close, the OpenOffice Base window closes. > However, I can now open the original file (DISTRIB.DBF) by using File | Open > from OpenOffice Calc This is because now, the file is properly opened - not assuming that it is an ODB file. So, the whole problem boils down to: "Open an existing database file" should not silently open anything, but only those files it recognizes as real ODB file.
accepting
I would like to suggest this (recognizing that it may be what you intended to do anyway): "Open an existing database file", when faced with a file not recognized as a real ODB file, should do exactly what "File | Open" does (for a dBase file, open it in Calc, and so forth).
Works in a OOO310 m6.
find more information about this CWS, like when it is available in the master builds, in EIS, the Environment Information System: http://eis.services.openoffice.org/ this is fixed in the current master. The current master is available at http://download.openoffice.org/680/index.html I close this issue now.
*** Issue 58220 has been marked as a duplicate of this issue. ***