We have a customer that has already budgeted a server/client upgrade from 5.5.05.2817 to 12.0.1 for 2013. They are using our 32-bit application in XP workstations that creates local and network connections with NW servers (using Novell client 2 SP2). Meanwhile, they need to install 5.5.05.2817 in their brand new Windows 7-64 bit boxes but the application is creating the errors below. They are currently using the same version of files accessing the NW servers without any issues. Everything seems to be installed correctly on the 64-bit boxes and the required ODBC entries can be seen from the administrator at c:\windows\SysWOW64\odbcad32.exe. The problem happens when the application tries to create the local and network database connections that seem to be dropped intermittently or can't be established at all. We have isolated the application to only local connections during the troubleshooting phase but the issue is still being always recreated. We are now in the process of checking for antivirus and firewall settings that might prevent the connections to be established. Windows 7 64-bit workstations Novell Client 2 SP2 Error: -100 Sqlstate: 08001 Unable to connect to database server: database engine not running Error: -101 Sqlstate: 08003 Connection not open: not connected to SQL database |
We were able to replicate the issues reported in this forum that were relared to the incompatibilities of the Novell client 2 SP2 installed in the 64bit Windows 7 workstations. Since other unanswered questions in this forum might refer to the same NW client causes I am adding the link for the Novell Client support for Windows 7 and Windows x64 incompatibility issues. The Novell Client for Windows XP/2003 (4.91 SP5) is a 32 bit application, and is not supported on 64 bit operating systems. Novell has no plans to develop a client for Windows Server 2003 x64 or Windows XP Professional x64 Edition. |
You may not have any luck running V5.5 on Windows 7 with reliability. My experience has been that the V5.5 engine will run for a while, but will eventually crash even if it is idle... I have extensive experience with this because Foxhound is repeatedly tested on Version 5 databases and these tests are usually run on Windows 7 because I don't really care if the target crashes... the tests are quick and can be easily run again. Thanks Breck. Does it make any difference whether the tests are done in 32 or 64-bit boxes? We haven't had reports of issues under W7-32bit.
(13 Nov '12, 17:40)
Derli Marcochi
Replies hidden
Don't know... all the tests are run on 64-bit versions of Windows 7. It's too bad, really, since 5.5 was (is) such a reliable product.
(14 Nov '12, 08:41)
Breck Carter
|
You're pushing your luck too far ;). Stick with NT/2000/XP or move from 5.5 to something more modern. And there is no sense to install 5.5 on the 64-bit OS anyway. 1
Agree. 5.5 will be used temporarily in the new 64-bit boxes (if it loads and stay connected of course!!)
(14 Nov '12, 09:32)
Derli Marcochi
1
If that's for temporary usage only, you might want to evaluate running SA 5.5 in a VM with e.g. XP as OS.
(14 Nov '12, 10:10)
Reimer Pods
|
Can you post the details of your client connection string?
The -100 error suggests that the database server hasn't been started yet. (How do you start the database server?). The -101 error suggests you tried a database operation on a connection that wasn't successfully connected yet.
The application creates 3 connections to local databases (loaded with rtdsk50) using the format:
and the Engine start command is: c:\sqlany50\win32\rtdsk50.exe -Q
The connections to the server use the format:
and the Client start command is: c:\sqlany50\win32\dbclient.exe -x tcpip{ServerList=C:\test\servers.txt} -Q
The database server running in production is started with:
We are concentrating at this point on the troubleshooting of the local connections only.
If you add
-o c:\dbsrv50.txt
to thedbsrv50
command, is there a console log file created?Is the database information normally stored in the DSN ('ccc', or 'ddd')?
If you're connecting over a network, does your DSN specify a host in the TCP/IP ("LINKS") options? If it's local, does it specify a database file or is the server launched in both instances the same way?
Please post all of the details of the DSN that you're using.
Jeff, The application has been in production under XP and W7-32 bit for years and the issues couldn't be recreated in our test environment (on a virtual W7-64bit)
In the customer site, we did setup the application to only access local databases for now so we won't need to deal with server connections (but the -o parameter can be added later for the network).
Yes, all the database information is stored in the ODBC entry as below:
Could it be some inconsistency when getting the information from the registry since it is a 32-bit application running on a 64-bit hardware?
No - this would manifest itself as a different error (e.g. "Datasource 'ccc' not found"), and Windows automatically handles mapping 32-bit applications to the 32-bit registry key ("Wow6432Node").
You can easily check for permission errors against the registry using Process Monitor.
You've provided a datasource without a server name specified though:
Server Name: <default>
What happens if you specify an engine name here?
As others have correctly commented, SQL Anywhere 5.5 is not supported on Windows 7. Your customers should stay on their existing environment until they are ready to move to a supported version.
We built a Dell desktop and a HP laptop with Windows 7 64-bit to try the same steps that are failing at the customer site. We just installed 5.5 and build # 2817 on both boxes and the application runs fine. The db connections are created and stay stable (no crashes).
Checked with the customer via Webex where 5.5 was uninstalled and reinstalled. The only visible difference during the 5.5 (and #2817) install in their site is on the screen below. If he leaves the default "Modify local machine environment variables" selected, the install creates an error and does not finish but if he selects the first option (Current User) the install seems to complete OK. Of course it is not the case because our application can't be loaded.
Would that explain anything about the issues? Is that a way to have 5.5 reinstalled using the default radio button selection?
UPDATE
Just received the event log info after the latest crash.
This is likely a permissions problem. Do you run the setup as an Administrator? ('Run as Administrator' ?) Remember that SQL Anywhere 5.5 has no concept of the User Account Control issues in newer Windows OSes.
As SQL Anywhere 5.5 is no longer supported by engineering, we will not be able to advise further on this crash information.
I would think you should be able to fix the 'Database engine not running' message by simply starting the database server and ensuring that the ODBC DSN can connect (newer versions of the ODBC driver have a convenient 'Test' button).
However, the server crash itself likely cannot be helped, as Breck has also experienced. Since there is no engineering support for Windows 7 / SQL Anywhere 5.5, we would strongly recommend that you do not proceed with this environment as a production solution.
Do you run the setup as an Administrator?
Yes - for both 5.5 and the 2817 build processes are started as Administrator.
The connection being tested is only for a LOCAL db.
I understand there is no longer support for 5.5 for ANY OS. As original described, we are only trying a temporary solution under Win 7-64bit as our common customer has dozens of brand new hardware sitting over there waiting for the 5.5 install to be done.
We asked for a hardware to be shipped to us so we could better research these issues.
@Breck, do you have any other suggestion to share?
Is this suggesting that you're seeing the SQLCODE -100, even though the database server process is running?
There is no engineering support for 5.5, that is correct. The product itself is still 'supported' on the original Windows platforms it was tested for however, assuming you have applied the supporting EBF version: http://www.sybase.com/detail?id=1023009
Are either the database server or client application running as a service?
Are you able to connect via dbisql reliably? 5.5 works generally seems to work on my 64-bit Win7 machine using dbisql. Unfortunately, the ODBC driver isn't self registering and I didn't use the installer so I can't see if your issues might be specific to ODBC.
How long does 5.5 run after you start it? In my experience, a few minutes tops, even if idle.
The workstations create local db connections with rtdsk50.exe (not as a service). In the Novell server there is a ncf file that starts dbsrv50.exe (with tcpip) - [see statements in the top of the post]. The customer has the server up and running for years so I don't see this portion as an issue.
Customer reported that when the application loaded it took about 20 minutes without crashing. This workstation will be available for troubleshooting at our office on Monday.
Should I open another question: Is anyone running 5.5 on 64bit Windows 7?
Yes, new questions should always be posted separately... this is primarily a Q&A site, discussions are secondary.
I left it running all weekend -- it's still going.
Thanks John!
It matches my test results as well. I left on for about 4h Friday, and didn't have any issues. I hope to have additional clues after installing one of their 64bit desktops in my office today.