I have an hsqlDB server running, with version 2.2.6, and a client application that remotely accesses this server, client version is 2.3.3.
Now I started a new project and wanted to access the server, but get an exception.
The server side log tells me:
org.hsqldb.HsqlException: Client driver version greater than '2.3.4.0' is required. HSQLDB server version is 'version'
The new client version really was 4.2.0, then I downgraded to 2.3.4 with the same result. Further downgrade to 2.3.3 avoided the problem, but can't be called a solution.
I don't dare upgrade the server (never touch a running system).
One strange thing that strikes me is the
version is 'version'
part of the error message.
That looks as if someone had forgotten to code the real version number.
Alas, I can't find source code.
Question is: has anyone seen or heard of that problem, and knows more about the reason?
The client-server protocol changes in some versions of HSQLDB. Each version of the Server can be accessed from clients that are compatible with it.
There was a bug (now fixed) only in error text reporting the mismatch. The actual check for compatibility does work, as you found out.
You do not need to change your server, as it works fine. Just use a compatible client.
Related
I maintain a legacy website written in asp classic that uses the MSXML2.XMLHTTP.6.0 DLL heavily and today all of a sudden it is throwing an error advising it can’t find the specified DLL. I did a check and the DLL is there and is registered correctly on the server.
Does anyone know if this DLL is no longer supported in Windows?
I have now resolved this (for now). The issue was with one of our API providers not the dll. Here was their response:
"We found a cipher that is not vulnerable and still supported on win 2012. Could you please test if you have an issue connecting using Win2008? We could leave it enabled for a longer period."
Enabling this cipher is what fixed the issue.
We have a situation where IBM Data Replication CDC for Db2 on i ver 6.1 (AS400) is installed as the source and Oracle 10.2.x being the target. A hardware upgrade is being scheduled on the source with a new AS400 box coming in, the existing database would be migrated/transferred to the new box. The Oracle box will stay the same and only an upgrade of the CDC agent is to be done. Management Console and Access Server are going to be upgraded too as part of this exercise.
In this scenario, we want to install CDC ver 11.4 on the new AS400 box to take advantage of the latest version and fixes. My queries are, (some might be silly, my apologies)
Would this be an install or upgrade on the new AS400 box as the database contains CDC related information?
What would happen to the subscriptions, would they have to be created again or an export/import of subscriptions work?
Will a refresh have to be triggered?
Given the target is the same and source is a new server, what are the implications and how to resolve them?
You should be aware that CDC v6 and CDC v 10.2.x are no longer supported (except for the zSeries 10.2.1 version) so if you have any issues during your migration process you may find it difficult to get support.
In general terms, you should be able to install something like CDC 11.3.3 on the current iSeries in advance of the migration as this version of CDC supports OS/400 6.1 and 7.1 7.2 and 7.3. Then you can save/restore the CDC product library along with all the other libraries. Do not forget to add the TCP/IP listener port service as well. If there is a change of hostname or IP address, you should follow the documented procedure to update the datastore properties in the Access Server https://www.ibm.com/support/knowledgecenter/SSTRGZ_11.4.0/com.ibm.cdcdoc.mcadminguide.doc/tasks/handlinghostportforsource.html
Before you restart operations on the new iSeries, you will either need to mark table capture point for all source tables or use SETJRNPOS to manually specify the restart position for replication as the target bookmarks are based on the old journal receiver chain and on the new system this will different
I prefer to upgrade pre-install mainly because it avoids making two changes at the same time. If you had an issue with CDC after migration and then upgrading you would have to determine if it was the new version or the migration that was the cause. However, upgrading the migrated CDC instance immediately after the migration should be OK.
If the IP address or hostname used in the Access Server datastore configuration is changed, you will need to change this following this procedure
https://www.ibm.com/support/knowledgecenter/SSTRGZ_11.4.0/com.ibm.cdcdoc.mcadminguide.doc/tasks/handlinghostportforsource.html
I have a server which has been upgraded from IBM Worklight 6.0 to IBM Mobilefirst 6.3
The server is currently running older versions of my mobile application, which do not have AppAuthenticity enabled.
When I uploaded the newer version of Application, AppAuthenticity option became enabled ONLY for one (windows) environment, while others stayed disabled.
After a restart, Windows Environment version became like others, while iPAD environment started giving option to change the AppAuthenticity.
I listed the application through WLADM CLI, and it gave me below error:
XML validation error, reading from
https://URL/wladmin/management-apis/1.0/runtimes/worklight/applications/MYAPPS?locale=en_US:
cvc-complex-type.4: Attribute 'downloadLink' must appear on element
'applicationEnvironmentDataAccess'.
Please note, the application if ran alone on other server is working fine with same Application-descriptor and WAR file, only when Old and new versions are uploaded on same server, this problem comes.
Are you saying your server has a single .war file with 2 apps on it, one from 6.0 and one from 6.3?
There are very different Application Authenticity Protection implementations in 6.0 and 6.3. These cannot co-exist in the same single .war file.
You need to deploy to your application server 2 .war files - one for handling the 6.0 app and another for handling the 6.3 app.
Relevant user documentation can be read here: http://www-01.ibm.com/support/knowledgecenter/SSHS8R_6.3.0/com.ibm.worklight.upgrade.doc/devenv/c_upgrade_to_srvr_in_production_env.html
As Idan said, the 6.0 and 6.3 app can not be handled together, since I only wanted to enable the App Authenticity in the newer version, what I did as a workaround was to connect via WLADM tool and disable the App Authenticity for Older Versions via command line.
Below are the commands one needs to use:
\Worklight\shortcuts>wladm --url=https://server.url/wladmin --user=admin --passwordfile=password.properties
to verify the application's current Authenticity :
app version %CONTEXT% %APP_NAME% %Environment_Name% %versionCode% get authenticitycheckrule
To Disable
app version %CONTEXT% %APP_NAME% %Environment_Name% %versionCode% set authenticitycheckrule DISABLED
I have a problem connection to a SQL Server 2012 instance running on Windows Server 2012. I have a .NET 4.5 windows forms application installed on a client machine running Windows 7. The error I get is this:
A connection was successfully established with the server, but then an error
occurred during the pre-login handshake. (provider: SSL Provider, error: 0 -
The wait operation timed out.)
My connection string looks like this:
server=SERVERNAME;database=DATABASENAME;User Id=someuser;password=somepassword;Timeout=60;app=LabelMaker
I tried connecting to the SQL Server from the client machine using QueryExpress
and that worked! My app is 64-bit if that is of any help. I've checked every setting I can think of in SQL Server. No force encryptions are enabled on the protocols (shared memory and tcp/ip), the domain firewall is open on the server. I've tried various connection strings with all kinds of unheard off parameters, always the same result, failure.
I'm really confused about why it works with QueryExpress? My app works when connected to a remote instance of SQL SERVER Express on another machine, it also works if I run it on the SQL Server 2012 machine.
I've also tried connecting to the server from the client machine with LinqPad and this is also really weird, with the new version based on net4/4.5 (Version: 4.43.06) it fails but when I use the old version of Linqpad (2.x) based on net3.5 it works!
It seems like Panda Security is causing the problem, I ran
netsh winsock show catalog
and found a few panda entries, I then did a reset
netsh winsock reset
now my application works fine, I then rebooted the machine, ran the catalog command again,
the panda entries were back and my app is having the same problem as before.
Here are the Panda entries in the winsock catalogue: https://gist.github.com/pellehenriksson/5159883
All ideas and suggestions are appreciated.
UPDATE
Panda Security v5 is the cause of this problem, this has been confirmed by Panda support.
The root cause of the problem is explained by Alex below. The customer will do an upgrade to v6 of Panda Security, I will test again after the upgrade.
CONCLUSION
Moving to Panda Security v6.0 fixed this issue.
This seems to be a non-Microsoft related issue: Visual Studio 11 beta installation disabled my abillity to connect remote MS SQL Server but not local databases.
The ticket has been closed as external.
The only workaround available at this time on Microsoft Connect is:
Posted by Lars Joakim Nilsson on 5/4/2012 at 5:03 AM
My machine had this problem. The work around for me was to remove non-IFS LSP installed Winsock Catalog Provider. Se
http://support.microsoft.com/kb/2568167
/Lars Nilsson
The SetFileCompletionNotificationModes API causes an IO completion port not work correctly with a non-IFS LSP installed link gives the resolution:
Not specifying the FILE_SKIP_COMPLETION_PORT_ON_SUCCESS flag or
removing any non-IFS Winsock LSPs installed. Also moving from a
non-IFS LSP to Windows Filter Platform (WFP) can resolve this issue.
So, you should remove Panda Security or, as an alternative, you may try to execute netsh winsock reset as a pre-build command (although I'm not sure if this is effective without a reboot), which would let you develop/debug your application.
[UPDATE]
More information about application compatibility is given here: Application Compatibility in the .NET Framework 4.5:
Data
SQLClient
Feature
Ability to connect to a SQL Server database from managed code that
runs under the .NET Framework 4.5.
Change
The existing synchronous API code path was modified to add
asynchronous support.
Impact
The presence of non-IFS Winsock Base Service Providers (BSPs) or Layered Service Providers (LSPs) may interfere with the ability to
connect to SQL Server. For more information, see
SetFileCompletionNotificationModes API causes an IO completion port
not work correctly with a non-IFS LSP installed on the Microsoft
Support website.
I hate to say it, but restarting Visual Studio and my Microsoft SQL Server Management Studio solved this problem.
I have a Firebird 2.1.1 database deployed over a LAN. In a recent upgrade I used an FB internal function (COALESCE). When I was testing my Delphi app on my development machine there were no problems.
But when I tried to run a query on a production machine I received an error message telling me that the function (COALESCE) was unavailable.
Coalesce is a built in internal function in FB. It is not a UDF or a stored proc, it is built in.
Q: Why does a query using Coalesce work on my development machine but not a production machine?
Some more Info:
XP pro SP2 on both
My program is developed in Delphi 3.0 with BDE
BTW: I installed FB server on the workstation (production machine) and, low and behold, the query using Coaclesce works! I thought Coaclesce was an internal function?! I don't want to have to install FB Server on every machine. There are over seventy workstations in three different locations.
Normally I have FB (ver 2.1.1) installed on one machine running XP. This is my designated database server. All workstations running my app get their data from this server. I upgraded my app and changed the schema of the FB database that resides on my server that my client side app uses. One of the changes that I made was that I am using FB internal funcations for the first time. Specifically I am using function COALESCE. When I run my app on a workstation I get the following error message:
-SQL error code = -804
-Function unknown
-COALESCE
The app running on the workstation is running a select statement against the database on the server that uses COALESCE.
Here's the interesting part: The query containing COALESCE ran fine on my development machine (which is another workstation on our network) but not my users' workstations (production machines). So I asked myself "What's the different about my development computer?" Well it has FB server on it. So I installed FB server on a user's workstation (FB is now on our server + on the workstation running my app) and: I don't get the error anymore! My app is still using the server's database (not the workstation's) but it's as if by having a full FB server on the client workstation my app can now find the internal FB functions.
I have been assuming that FB internal functions are part of the server install. They don't need to be copied to workstations and they don't need to be declared. They are like SUM, MIN, MAX or AVG.
Q: Why don't Firebird Internal functions run on Firebird client conmputers?
The Firebird's client library "fbclient.dll" (or perhaps renamed as "gds32.dll") parse the statement and validates the SQL keywords that are used.
It is not necessary to install the server on the client machines.
What happened is that the machine was running with an old version of the client library (maybe BDE has been distributed with an old "gds32.dll") that not recognize the "COALESCE" keyword. When you installed the server version 2.1.1 it also install the updated client modules, and possibly replaced the old "gds32.dll" in the system directory for a "fbclient.dll" (option checked by default in the server installer) compatible with Firebird 2.1, renamed as "gds32.dll".
You can attempt to reproduce the problem, search for all copies of "fbclient.dll" and "gds32.dll" in the workstation, and then notice if they are really old version, and try replace only this specific files, without install the server in the client machines.