I'm trying to write a small program for CRUD operations against an old Pervasive 9 database, but as soon as I try to get a connection with Drivermanager.getConnection it throws
"java.io.IOException: LNA session closed"
I've read THAT post but copy/paste on that code didn't help me. Could be it configuration on that Pervasive 9 machine? Is it JDBC10 driver that won't play nice with older versions?
Or.. is it me being stupid? (everything is always possible)
Regards
According to Pervasive, using a newer client to an older engine is not recommended. This is documented at http://docs.pervasive.com/products/database/psqlv11/wwhelp/wwhimpl/js/html/wwhelp.htm#href=getstart/installprep.02.6.html#149125.
That doesn't mean it won't work but there's no guarantee. There are reports of the Btrieve interface working properly but the relational (SQL, ODBC, JDBC) side fails more often mainly because it changes between major versions where the Btrieve side stays the same.
I would suggest using the v9 client (and JDBC driver) or upgrading the server to v10.
#elwis your trouble it's the conecction with the database. I recommend you, make a connection using a reverse ssh tunnel against the machine where you have the database first with port by default of pervasive.
Something like: ssh user#yourmachine -L 15831:192.1X.X0.X80:1583
Then, using the tool can generate the connection DBeaver to see and do what you need.
That works for me.
Good luck.
Related
I have an ODBC database on Windows Server 2008. Typically I use Access or PHP when I want to work with it, but for reasons I need to connect to it with Java now and it's proving more difficult than I thought it would. Most other questions on this topic are dealing with MS Access, but I'm not in this case and while maybe I could create an MDB file with linked tables then use something like UCanAccess I really don't want to try going there.
So in PHP I can connect to the database with the line:
$conn = odbc_connect("ODBC;ServerName=127.0.0.0;DSN={$odbc_name};",$user,$password);
Is there something equivalent I can do with jdk1.8.0_181? Or is this something where I'd have to revert back to jdk1.7 and use ODBC Bridge?
Edit: I should add that the DB I'm trying to access is not on SQL Server, but rather a more obscure platform called Pervasive SQL. It is still ODBC though.
I have a remote Linux server and I want to connect to an Oracle database which is in another server, using ojdbc7 lib
When I try to connect directly to the database from my Windows PC, using the same client and ojdbc7 lib, I have reasonable connection time.
Now, when I want to connect through my linux server, I get extreme slowness, just in the connection time. . Once connected, the execution is OK.
I have read about adding -Djava.security.egd=file:/dev/urandom like in this post, but nothing happened.
What could I do to fix this delay in setting up a connection from linux?
Close, but no cigar: it's "file:///dev/urandom", or one of the variations, see eg. https://anirban-m.blogspot.com/2014/03/jdbc-connection-reset-error-java.html
I noticed you are using version 12.1.0.1.
There was an Oracle bug where JDBC connections could take excessive times because the data being sent required the listener to perform a DNS lookup for each connection and that could apparently be very slow for some reason.
The bug was fixed in 12.2 and there is a back-ported fix (patch) for 12.1.0.2.
In the meantime, try getting your Linux admin to go through the process of tuning DNS lookups on that server. E.g., tune /etc/resolv.conf or enable the name service cache daemon. I'm not really expert in Linux administration so I can't help you. But based on the problem and the version you are using, that's where I'd look.
I want to connect oracle database without oracle client.After searching that how can i do this, figure out I must be use oracle instance client . But how can I use this? Icant find something about that.
The recommended (and most frequently used) JDBC driver for Oracle is the "thin driver". It doesn't need anything installed on the client (and is free).
This FAQ might be useful : http://www.orafaq.com/wiki/JDBC
Oracle client is a software that can easily be found and downloaded from oracle.com website. It has different versions for Windows, Linux, etc. After installing appropriate client, you will be able to communicate with the database by specifying its parameters such as host address, username, password etc. Without it, I think it's not possible to communicate with the database server.
http://www.orafaq.com/wiki/JDBC
On this page it says: "You must use a JDBC OCI driver appropriate to your Oracle client installation." What I understand from here is that you should use JDBC driver in your application, but without client installed, it will be nonsense.
I've got a database that is mirrored using SQL 2008 Mirroring.
I have a java application, running on Linux, using the Microsoft SQL
type 4 JDBC drivers.
I have this setup duplicated as a QA environment.
On my QA environment, when I manually fail over the database,
providing a successful connection had already been made, the failover
was completely transparent. I did not have to implement anything in
order to get the application to talk to the new Principle (Old
mirror).
In the live environment however, the connections stop working once I
have manually failed over.
There are quite a few things different between the live and QA environments, but not anything I'd consider fundamental to this process, communication between databases is all very localised in both situations and there are no firewalls (Except the ones built into Windows Server 2008) between my java app and the Windows boxes running SQL 2008.
Does anyone have any ideas about how I can go about diagnosing this issue? Or can anyone tell me how this failover transparency occurs so I can work out how to diagnose this myself?
This behaviour is handled by the SQL Server provider as part of the Client Redirect behaviour. This was part of the SQL Server 2005 JDBC (Java Database Connectivity) 1.1 Driver, I'm unsure if that provider was directly used for the new type 4 drivers though?
In your live environment, is your application successfully connecting to the primary server before it fails over, so it is able to cache the failover partner and make use of that when the failover occurs?
To be sure, you can explicitly state the failover partner in the connection string, which is the recommended practice:
jdbc:sqlserver://serverA:1433; databaseName=AdventureWorks; integratedSecurity=true; failoverPartner=serverB
The full documentation of the redirect behaviour can be found here.
The addition of the failover documentation here suggests that it could be a manual consideration.
I am having a problem with Java DB that I just don't know how to resolve. I am creating a DB and connecting to it using Java DB's native JDBC driver. If I relocate that database physically and try to connect to it using its new path, I consistently get XJ004 errors:
ERROR XJ004: Database 'blahblah' not found.
I am sure I am using the correct connection string. Is there any possibility the DB is somehow getting corrupted? Or is there some encoding of the DB path in the DB such that if you relocate a Java DB it gets confused?
I'm really at a loss here. :( Please help!
Jim
Have you verified that this error message isn't also used when there's no listener on the host machine ... and were you using JavaDB on your local machine before the relocation? Many database systems (and I'm not that familiar with JavaDB) ship set-up to only allow connections from localhost for security reasons. On PostgreSQL for instance, you have to allow TCP connections and bounce the daemon to obtain a remote connection.
Anyway ... since the problem started when you when remote, look for issues related to that first! (And if you can run your application on the remote machine, does that work?)
There must be a file named derby.log somewhere. Check the error there. If it is not detailed enough, try setting derby.stream.error.logSeverityLevel to a lower value. See the manual for more information.