i have a question about Firebird Client and Server versions. I know that the Database-File have to match the Firebird Server due to ODS Changes. i.e. Firebird recommends to Backup/Restore the Database-File between Server-Version 2.5.1 and 2.5.2...
But what about Client connections to the Server?
Which combinations are ok?
Client 2.5.2 --> Server 2.5.2 (should be ok. ;) )
Client 2.5.2 --> Server 2.5.1
Client 2.5.1 --> Server 2.5.2
Client 2.5.x --> Server 1.5
Client 1.5.x --> Server 2.5.2
Are there any known problems? What is the recommendation from Firebird?
Is it a good why to use always the new official Client? But due to we have a lot of Customer Installations i can not be sure that the server matches the client-version.
Hope someone can give me some advice.
The Firebird protocol has a versioning mechanism: the client and server negotiate which version of the protocol to use. Current Firebird server versions support all previous protocol versions of Firebird (upto and including Interbase 6.0 from which it was forked). This means that any Firebird client version can talk to any Firebird version. However if you use an older client, you can't use features added in newer protocol versions, and you won't be able to use some of the performance improvements in the protocol.
So: yes you can use older versions, but it is advisable to use the latest because bugs will have been fixed and new features or performance improvements have been added.
My answer only applies to TCP/IP connections. For 'local' connections with XNET or named pipes I know there were breaking changes between 1.5 and 2.0, and you might even need a client version that matches the Firebird server version.
For Firebird 3, using older client versions does have some caveats: by default Firebird 3 requires wire protocol encryption and a new authentication mechanism, both of which were introduced in Firebird 3 with wire protocol version 13. To be able to connect with an older client version you will need to make the following changes to firebird.conf and restart Firebird:
Relax the encryption requirement with setting WireCrypt = Enabled (default is Required)
Enable the legacy authentication with setting AuthServer = Srp, Legacy_Auth (default is Srp)
https://i.stack.imgur.com/mxQ7S.png
You cant read v2.1v database on v2.5 server.
You cant read v1.5v database on v2.5 server.
You can read v2.0v database on v2.1 server.
You can read v1.5v database on v2.1 server.
Related
I am using neo4j-connector-apache-spark_2.11-4.0.2_for_spark_2.4.jar this connector with spark version 2.4.4, scala 2.11.12 and neo4j 3.3.x
Throwing this org.neo4j.driver.exceptions.ClientException: The server does not support any of the protocol versions supported by this driver. Ensure that you are using driver and server versions that are compatible with one another, while trying to read data from neo4j.
TL;DR
This error means that the underlying Neo4j driver is either very old (unlikely) or too recent (most likely) for the target Neo4j server.
You should either downgrade the Neo4j driver (and hope it is still compatible with the Spark connector) or upgrade the 3.3 server to 4.4 or 5.x (since 3.3 has reached EOL in 2019).
Long version
Neo4j drivers negotiate a Bolt protocol version with the server after establishing a connection. Drivers have a limited range of versions they can offer, so older protocol versions are excluded from newer driver releases. The server also offers a range of protocol versions it can support. The server then selects a version from the overlap of all these versions.
Since Neo4j server 3.3 has reached end of life in 2019 (see https://neo4j.com/developer/kb/neo4j-supported-versions/), the associated Bolt protocol version (1, according to the docs) has not been included in any recent drivers' negotiated version range.
Because of this, there is no overlap so no protocol version can be picked up and this error happens, reported back by the Java driver as a ClientException.
I need to connect to an Oracle 9i server from my machine using SQLDeveloper. I already have a functioning version of SQLDeveloper 18.2 + Oracle Client 12 for more modern databases, but for this connection I want a separate older version of SQLDeveloper.
I've installed SQLDeveloper 3.2.20.09 in a separate folder on my machine and can launch it, but it defaults to finding the ojdbc6.jar file from Oracle Client 12. if I go to Help > About and select properties, the jdbc.library says jdbc.library /C:/app/client/product/12.1.0/client_1/jdbc/lib/ojdbc6.jar
and if I try to connect I get the error ORA-01460: unimplemented or unreasonable conversion requested
I tried putting the path to the SQL Developer 3.2 install first in the PATH variable, but no difference. Is there a way to tell SQL Developer which jdbc driver to use for Oracle ? (maybe in sqldeveloper.conf)
The official answer is:
use the jar (driver) we ship with the product OR
use a Thick Client, and we'll pull the jdbc driver from an Instant Client or Oracle HOME on your machine
The 2nd option will work so long as you don't try to go back back or forward in time to the point that the software will recognize/support the driver.
In other words, you can't tell SQL Developer 18.x to use a 9i Home, we have a hard dependency to require at least a 11gR2 client (I believe, it could actually be a 12c based client which is required).
You'd be better off getting your data out of that ancier 9i Database and into a modern 12 or 19c Oracle instance.
but it defaults to finding the ojdbc6.jar file from Oracle Client 12.
Sounds like you've managed to get a thick connection defined, go into preferences and disabled on the advanced page any reference to OCI or Thick, then it will use the jdbc driver shipped with SQLDev.
I was using PostgresSQL version 9.6 with JDBC driver 9.4-1206-jdbc42 to connect to Java. I was using the SimpleJDBCCall of Springs to connect to the database.
However, after the upgrade of PostgreSQL to 10.5, we are unable to use the SimpleJDBCCall API. Any light on this issue will be of great help.
You should never use a version of the JDBC driver that is older than the PostgreSQL server release.
The recommendation is to always use the latest driver version. A new driver will know how to talk to an old server, while an old driver might not know how to talk to a new server.
There are many posts here and all over the web about getting the message:
Connection using old (pre-4.1.1) authentication protocol refused (client option 'secure_auth' enabled)
when trying to connect a a MySQL database. In my case, it's coming from MySQLWorkbench version 6.3 newly installed on a almost as newly install Ubuntu 15.10 system.
The advice is always to update the password on the database to use the new authentication.
However, that is not my problem, and that's not what the message says. It says that the OLD authentication is being used when the database wants the NEW authentication.
This version of MySQLWorkbench has a checkbox that tells it to use the OLD authentication, which is unchecked, but, from the message, it appears to be using the OLD authentication all the time.
I can connect to the database easily from version 5.2 of MySQLWorkbench running on Mac OS X.
I tried installing an older version of MySQLWorkbench on my Ubuntu system, but there were numerous errors with the package, which is intended for an earlier version of Ubuntu.
Any ideas about how I can force MySQLWorkbench to use the NEW authentication? I tried setting:
useLegacyAuth=0
but that did nothing.
OK, got the answer. The hosting outfit (Siteground) sets up MySQL passwords to work with EITHER the legacy or the new protocol. I don't know if this is homegrown, some sort of plugin that's generally available, or a standard MySQL feature. With this option, MySQLWorkbench fails to connect and erroneously reports the problem as the server not supporting the old protocol. Probably it's just confused by the error response which its programmers didn't anticipate.
Siteground very quickly set my password to use the new authentication ONLY upon my request, and then MySQLWorkbench connected with no problem.
I have to set up a Hornetq Core-Bridge to a Hornetq 2.1.X Server, but I would like to use a more updated version on my side of the architecture (2.2.X). Is it compatible?
I haven't found info about it on documentation (as always btw, regarding to hornetq).
Obs: The 2.1.X Server is running on a JBoss AS, and mine is on stand-alone mode.
Until hornetq 2.2.2, hornetq didn't have version compatibility support. That means that you would need all your servers on the same version. (same as you would need for your clients).
After hornetQ 2.2.2 we offer version compatibility, however the client has to be older than the server. We don't test a 2.2.5 talking to a 2.2.2 server.
So, if the core-bridge is installed in a 2.2.2 talking to a 2.2.5, you would be fine.
a 2.2.5 talking to a 2.2.2.. probably not
A 2.1.X talking to 2.2.x.. definitely not.