Description: One last effort to get LibreOffice Base working again, otherwise I may be compelled to find another program. During previous efforts, it has been suggested that I have not always provided the detailed information that the very patient responders could have used to solve my problem; this time I will do my best to tell you everything. Towards the beginning of December, I was happily updating my database, which is a LibreOffice Base database (entitled REFS3) but based on a Microsoft Access (mdb, not 2016) database (entitled REFS2), when LibreOffice stopped responding. In the past, I have always found that this indicates that an update is available, so I updated LibreOffice - to version 5.3.7.2 x64. From that moment, though I can open the opening screen of REFS3, as soon as I select a table (or query or report), all I get is a pop-up window stating ‘The connection to the data source REFS3 could not be established. The connection could not be created. Perhaps the necessary data finder has not been installed’. On seeking help, I was told that LO 5.3.7.2x64 is a 64 bit version and therefore requires a 64 bit Java JRE. So I upgraded Java to Oracle version 1.8.0_151 which I am assured is a 64 bit version. After several more days of effort, I managed to get the JRE which Java said was installed to appear on the LO Java Options screen (Tools, Options, Advanced), and further that the Parameters screen and the Class Path screen are both empty. I have ensured that both databases REFS3 and REFS2 are registered, that Microsoft Access and the correct address of the REFS2 database appear at the bottom of the opening screen of REFS3, that REFS2 and REFS3 are both set to open with LO Base. But despite all this advice and action, all I get when I open REFS3, and select a table, is that pesky pop-up window mentioned above What I have not altered is the LO /tools/options/LibreOffice Base Connections screen. The current connection is com.sun.star.comp.sdbc.ODBCDriver. Connection pooling is enabled, but pooling is set to NO on all the entries. The problem is not fixed by going into Safe Mode. If anyone can advise me on how to get my database working again, I would be very grateful. Actually, I have three similar databases, but this one is the most complex (three tables) and if this one gets fixed, I reckon I will be able to sort out the other two. Steps to Reproduce: 1.Enter LibreOffice 2.Select REFS3 database 3.Select any table, query or report Actual Results: The pop-up window described above appeared Expected Results: The appearance of the table.query/report on screen Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: StartModule [Information guessed from browser] OS: Windows 10 Home OS is 64bit: yes Version: 5.3.7.2 (x64) Build ID: 6b8ed514a9f8b44d37a1b96673cbbdd077e24059 CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; Locale: en-GB (en_GB); Calc: group User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
One thing I do not understand is that the 'Help; About LibreOffice' screen says Windows 6.19 whereas my Systems screen reassures me (as did Dell who sold it to me) that I have Windows 10 Home installed.
Re: comment 1: Yeah, LibreOffice used to report the wrong version number, but that’s already fixed in 6.0. See bug 100233.
Jean-Pierre: knowing your work about Access part on LO, thought you may be interested and have some idea here.
@ Chris Grove Could you please attach the REFS3 and REFS2 database files (or any other test case that has the same issue) ? I will not be able to reproduce the incident without them. Thanks in advance.
REFS 2 is now nearly 24 Mb and I think it somewhat overkill to send all that to you. What I will do is to ensure that another database using KITS3 and KITS2 (only just over 1 Mb) is at the same state as the REFS databases and send you that. Same problem, though a much smaller and simpler database (2 tables not linked). As before KITS3 is the .odb and KITS2 is the .mdb. Wait while I do that.
Created attachment 138816 [details] odb database file which ought to connect to KITS2 Since I reported this bug, the list of registered databases has disappeared leaving only my Bibliography showing. Should I reregister my databases, and , if so, which ones - odb, mdb or both?
Created attachment 138817 [details] Access .mdb databse file to which KITS3 should connect
Created attachment 138840 [details] Screenshot MSAccess error message
I could reproduce the problem in LO 5.4.3.2 under Win7 (x64). However, when I tried to open KITS2.mdb with MSAccess itself, I got the error message stored in the attached screenshot. This could explain, maybe, that the sdbc driver gets stuck. Of course, only if you get the same message, Chris, if you try to open the same .mdb in your environment. Can you please report on this ? Thanks.
(In reply to Chris Grove from comment #6) > Created attachment 138816 [details] > odb database file which ought to connect to KITS2 > > Since I reported this bug, the list of registered databases has disappeared > leaving only my Bibliography showing. Should I reregister my databases, and > , if so, which ones - odb, mdb or both? I doubt registering the database could solve the problem. Anyway, only odb's should be registered. It does not make sense to register an mdb.
Jean-Pierre Many thanks for your attention. I do not have MSOffice installed, so I cannot access the .mdb databases direct. If I access it/them through LO, I get the pop-up window as described above. Ability (which I installed in desperation to get some access to my data) can access the tables in REFS2 and KITS2 (but I guess my queries and reports will have to be rewritten in 'Ability-speak' which I have not attempted) without any problems. I have verified with Ability that their program does not alter the .mdb file format.
Just another thought. The database KITS2, back in the days when I was actually using MSAccess as my database, used to have a password required to enter it. This has not been requested ever since I changed to LO, but the file KITS.ldb is still there. I could attach it if you think that could be the cause of the problem. However, it has been so long since I needed it that I have forgotten what the password was, but it might have been PANZER. The REFS2 database also had a password PANZER. When I changed to LO, I was indeed asked for this password every time I entered the database, up till the time that I updated to LO 5.3.7.2, since when I have not been asked. Probably a silly question, but should the odb file be looking at the ldb file and not the mdb one? Chris
If I try to access .mdb files direct, I get a LibreOfffice Writer document which starts ####Standard Jet DB##### followed by an unintelligible series of, often unusual, characters. If I access .ldb files direct, I get another Writer document which says DESKTOP-E1AT4QK# (that is for KITS2.ldb) then a number of spaces and then Admin# Chris
(In reply to Chris Grove from comment #13) > If I try to access .mdb files direct, I get a LibreOfffice Writer document > which starts ####Standard Jet DB##### followed by an unintelligible series > of, often unusual, characters. > > If I access .ldb files direct, I get another Writer document which says > DESKTOP-E1AT4QK# (that is for KITS2.ldb) then a number of spaces and then > Admin# > > Chris This is not relevant with the discussed issue: LO is not prepared to open .mdb or .ldb files directly. When LO is invited to open an unknown format, it always tries to open it with Writer combined with one of the many builtin format convertors. If the format is not supported it gives unpredictable results like the one you observed.
I could reproduce the incident with Win7/LO 5.4.3.2. I got the same error message as described earlier while setting up a new Base document linked to an own MSAccess database (.mdb format). I tried both the "SDBC/Microsoft Access" and "ODBC/Microsoft Access" drivers. (Note that accessing a .accdb database with the "SBDC/Microsoft Access 2007" driver worked fine.) I changed to status of the bug to NEW. My conclusion is that there was indeed a regression some time before LO 5.3.7. Some components were not included in the build anymore ? But identifying which commit could have been the cause of it is very far from my competences.
Thankyou for your efforts, Jean-Pierre. You may well be right, but I was accessing and updating my database immediately before updating LO! Chris
Have never used Access and *.mdb. Only one idea: Isn't *.mdb a database for 32bit? Could this be the problem? 6bit LO, 64bit Java and 32bit *.mdb-file? See also https://bugs.documentfoundation.org/show_bug.cgi?id=97395
Well; I suppose that could be the problem. Until I updated my LO, I had never bothered with the difference between 64 bit and 32. But 64 bit LO still offers you the possibility of connecting to an .mdb file. If it can't work, then perhaps it should not offer it as a possibility. Maybe I'll have to go to Ability after all. Chris
The .mdb format for MSAccess databases is not related to 32/64 bits. It is related to the version: .mdb <= 2003, .accdb >= 2007. Note that MSAccess >= 2007 support both internal formats. I could open the KITS3.mdb file under Win7(x64) with MSOffice 64 bits. But I could not open any *.mdb file from LO 5.4.3.2 (64 bits still under Win7). My conviction remains that the proposed MSAccess driver in LO does not work correctly anymore (or is not correctly installed ... ?). LO - even 64 bits version - should be able to open an uncorrupted .mdb file. It it is not, then it is a bug.
Saw this bug today and felt somewhat responsible. I originally answered Chris Grove on the ask.libreoffice site. At the time I wasn't aware the Access connection does not work in Windows 64-bit. Recent activities have brought this to light. I am posting because there is a way to do this in 64-bit if you use a JDBC connector - UCanAccess. Have posted the "How To" steps here: https://ask.libreoffice.org/en/question/145877/mdb-files-not-loading-to-base/ Sorry for any inconvenience & hope this helps. I also believe this is still a bug, but for now there is another way without going to 32-bit.
Hi all Many thanks for numerous suggestions, some very useful and some not quite so useful. Stang's suggestion worked to get the database working again, but I still had the problem of passing the required parameter into the database in order to create the report I needed. However, from elsewhere I got a suggestion to create a single record table containing that parameter, and connect that into the database, and that finally got it to work and create a usable report for me!
I tested in LO 5.3.7.2 with no error message.I could even edit tables kits1 and models1. OS: Win 7 Java Update 71(64-bit) 8.0.710.15
Thanks to everyone for their efforts on my behalf. A suggestion (from the Ability helpline) to use a single record table to pass the vital parameter to the report has worked. I am now able to create a usable report from my databases, using either LibreOffice Base or Abiity. I suspect I will have to go through the process proposed by Stang above in order to access the Kits database in LO, but I can use that in Ability without problems. Since, in the past, the crashing of LO Base has indicated to me that an update needs to be done, I shall await the next update with interest! Chris
Based on from I understood here, I'll close as WFM. Because open bug needs to have problem and required solution. And here we had a problem and some workaround, but no requirement for a solution. I suggest that issue is discussed in See also bugs.