I created such odb and used it last time on 25 april 2019 with the LO version current at that time.
When I open it now, the odb at first sight opens correctly, but as soon as I click “Tables” and fill in the password for the postgres database I get “The class postgres could not be loaded”.
I can create a new odb with the same connection, and that one works OK.
How do you connect to Postgres? Direct connection, ODBC or JDBC.
Where is the Postgres server running?
Which system do you use (Windows, Linux …) ?
Also possible: upload the two files - the working (new) version and the old version, which doesn’t connect. Connection is written in content.xml inside the *.odb-file.
How I connect??? according to the content.xml: jdbc.
The Postgres server is running on a Linux Mageia 8 desktop PC. The odb (both old and new) have been tried from the same desktop and from a Windows 10 laptop with the same result.
I will upload the files. kassa.odb is the old one, kassa2.odb is the newly created one. And BTW the connection is to a postgres-gnucash database on the desktop.
kassa.odb (1.8 KB)
kassa2.odb (2.2 KB)
Old: jdbc:host=localhost:5432 dbname=gnucash
New: sdbc:postgresql:host=mach1.hviaene.thuis dbname=gnucash
In the second case, the built-in driver is used.
I can see the difference, but do you think it is acceptable for someone who has built an application on such configuration that it gets broken by a new version??? Remember that the old version worked like that and it was the default at that time.
Remember that you are on a user-to-user help site. You post your problem here seeking for a way to do your job done; and you get the best solution that other users could suggest. It might help you, but it should not be confused with proper debugging, and if needed, a bug report. No users here would “think it is acceptable” - but it’s not the issue to discuss here.
1 Like
Try to connect through the appropriate JDBC driver. Maybe the problem is there.
Fair enough, I’ll log a bug.
FTR: tdf#144035
If the old database has connected by JDBC and the new database is connected directly, you should have a look at the JDBC-connector you used with the old database.
Tools → Options → LibreOffice → Advanced → ClassPath will show me the JDBC-connector I am using here. Could also be there is a JDBC-connector installed with your system, so the connection to Java will connect also to PostgreSQL through JDBC.
Well, I haven’t checked my Win10 laptop installation yet (I don’t use it so often), but in my Linux desktop the Classpath is empty. And yes, LO has been installed from the rpm’s from the LO Download pages.
This is not the first time this happens. In the forum I came to the same issue with LO 6.1.something. That wad corrected in a later subrelease.
It has nothing to do with LO. You have to see if the postgres-JDBC-connection is installed on the system. It could be connected together with the JRE (in my rpm-base system OpenSuse 15.2 I could install it with Yast) or it could be downloaded separately and set in classpath. If it doesn’t appear in the path for JRE or in classpath of LO the connection with JDBC is impossible.
If it works in the past and you haven’t done anything for this the JDBC-driver for postgres will be installed by your rpm-system.
Linux Mageia 8 has LO 7.0.X in its repos. But that version had a problem with calling reports from standalone forms. That worked OK in LO 6.X and is again OK in 7.1.X, That’s the reason I went to the TDF-downloads.
So yes, there would be a postgres-JDBC package in the repos, but from an older version of the LO installed, and I will check itn , but I fear the dependency checking will cause trouble.
Then I don’t know whether enforcing the installation omitting the dependency is such a good idea.
postgres-JDBC package is unrelated to LibreOffice in any way. It is a separate package, which LibreOffice does not depend on - the same way as it does not depend on e.g. postgres itself installed. It’s just that if you want any of your applications to connect to postgres using JDBC, you need that package installed separately.