Error -100 on 64-bit workstation

[former_SQLA_member1694870]

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

[jeff_albion]

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.

[former_SQLA_member1694870]

The application creates 3 connections to local databases (loaded with rtdsk50) using the format:

WITH ENGINE odbc DECLARE localConn CONNECTION FOR  USER 'aaa' PASSWORD 'bbb' DATASOURCE 'ccc'

and the Engine start command is: c:\\sqlany50\\win32\\rtdsk50.exe -Q

The connections to the server use the format:

WITH ENGINE odbc DECLARE netConn CONNECTION FOR DATASOURCE 'ddd' USER 'uuu' PASSWORD 'ppp' CONN_STRING "DBN=nnn;ENG=eee"

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:

C:\\\\SQLANY50\\\\win32\\\\dbsrv50.exe -c 8m -ti 0 -tl 480 -n dbserv -x tcpip{dobroadcast=no} @c:\\test\\dbfilesmiser.txt

We are concentrating at this point on the troubleshooting of the local connections only.

[jeff_albion]

The database server running in production is started with:

If you add -o c:\\dbsrv50.txt to the dbsrv50 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.

[former_SQLA_member1694870]

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?

[jeff_albion]

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.

---

FOR  USER 'aaa' PASSWORD 'bbb' DATASOURCE 'ccc'

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.

[former_SQLA_member1694870]

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.

 Log Name:      Application
 Source:        Application Error
 Date:          11/15/2012 2:47:55 PM
 Event ID:      1000
 Task Category: (100)
 Level:         Error
 Keywords:      Classic
 User:          N/A
 Computer:      test
 Description:
 Faulting application name: rtdsk50.exe, version: 5.5.5.2509, time stamp:
 0x37683388
 Faulting module name: rtdsk50.exe, version: 5.5.5.2509, time stamp:
 0x37683388
 Exception code: 0xc0000005
 Fault offset: 0x00090ea2
 Faulting process id: 0x940c
 Faulting application start time: 0x01cdc3697654eaf0 Faulting application path: c:\\sqlany50\\win32\\rtdsk50.exe Faulting module path: c:\\sqlany50\\win32\\rtdsk50.exe Report Id: 590bb5cd-2f5d-11e2-b6aa-3c970e340ecb    
 Event Xml:
 <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
   <System>
     <Provider Name="Application Error" />
     <EventID Qualifiers="0">1000</EventID>
     <Level>2</Level>
     <Task>100</Task>
     <Keywords>0x80000000000000</Keywords>
     <TimeCreated SystemTime="2012-11-15T19:47:55.000000000Z" />
     <EventRecordID>9066</EventRecordID>
     <Channel>Application</Channel>
     <Computer>test</Computer>
     <Security />
   </System>
   <EventData>
     <Data>rtdsk50.exe</Data>
     <Data>5.5.5.2509</Data>
     <Data>37683388</Data>
     <Data>rtdsk50.exe</Data>
     <Data>5.5.5.2509</Data>
     <Data>37683388</Data>
     <Data>c0000005</Data>
     <Data>00090ea2</Data>
     <Data>940c</Data>
     <Data>01cdc3697654eaf0</Data>
     <Data>c:\\sqlany50\\win32\\rtdsk50.exe</Data>
     <Data>c:\\sqlany50\\win32\\rtdsk50.exe</Data>
     <Data>590bb5cd-2f5d-11e2-b6aa-3c970e340ecb</Data>
   </EventData>
 </Event>

 *****Then this "Information" event occurred immediately afterwards.*****
 Log Name:      Application
 Source:        Windows Error Reporting
 Date:          11/15/2012 2:47:56 PM
 Event ID:      1001
 Task Category: None
 Level:         Information
 Keywords:      Classic
 User:          N/A
 Computer:      test
 Description:
 Fault bucket 888354610, type 1
 Event Name: APPCRASH
 Response: Not available
 Cab Id: 0

 Problem signature:
 P1: rtdsk50.exe
 P2: 5.5.5.2509
 P3: 37683388
 P4: rtdsk50.exe
 P5: 5.5.5.2509
 P6: 37683388
 P7: c0000005
 P8: 00090ea2
 P9:
 P10:

 Attached files:
 C:\\Users\\test2\\AppData\\Local\\Temp\\WERC591.tmp.WERInternalMetadata.xml

 These files may be available here:
 C:\\Users\\test2\\AppData\\Local\\Microsoft\\Windows\\WER\\ReportArchive
 \\AppCrash_rtdsk50.exe_f2d945ded7aa76414afa8b65c52b38af4ebff7a3_96f9c69a

 Analysis symbol:
 Rechecking for solution: 0
 Report Id: 590bb5cd-2f5d-11e2-b6aa-3c970e340ecb
 Report Status: 0
 Event Xml:
 <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
   <System>
     <Provider Name="Windows Error Reporting" />
     <EventID Qualifiers="0">1001</EventID>
     <Level>4</Level>
     <Task>0</Task>
     <Keywords>0x80000000000000</Keywords>
     <TimeCreated SystemTime="2012-11-15T19:47:56.000000000Z" />
     <EventRecordID>9067</EventRecordID>
     <Channel>Application</Channel>
     <Computer>test</Computer>
     <Security />
   </System>
   <EventData>
     <Data>888354610</Data>
     <Data>1</Data>
     <Data>APPCRASH</Data>
     <Data>Not available</Data>
     <Data>0</Data>
     <Data>rtdsk50.exe</Data>
     <Data>5.5.5.2509</Data>
     <Data>37683388</Data>
     <Data>rtdsk50.exe</Data>
     <Data>5.5.5.2509</Data>
     <Data>37683388</Data>
     <Data>c0000005</Data>
     <Data>00090ea2</Data>
     <Data>
     </Data>
     <Data>
     </Data>
     <Data>
 C:\\Users\\test2\\AppData\\Local\\Temp
 \\WERC591.tmp.WERInternalMetadata.xml</Data>
     <Data>C:\\Users\\test2\\AppData\\Local\\Microsoft\\Windows\\WER
 \\ReportArchive
 \\AppCrash_rtdsk50.exe_f2d945ded7aa76414afa8b65c52b38af4ebff7a3_96f9c69a</Data>
     <Data>
     </Data>
     <Data>0</Data>
     <Data>590bb5cd-2f5d-11e2-b6aa-3c970e340ecb</Data>
     <Data>0</Data>
   </EventData>
 </Event>

[jeff_albion]

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.

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.

Just received the event log info after the latest crash.

As SQL Anywhere 5.5 is no longer supported by engineering, we will not be able to advise further on this crash information.

Would that explain anything about the issues?

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.

[former_SQLA_member1694870]

Do you run the setup as an Administrator?

Yes - for both 5.5 and the 2817 build processes are started as Administrator.

Database engine not running message by simply starting the database server

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?

[jeff_albion]

Database engine not running message by simply starting the database server

Is this suggesting that you're seeing the SQLCODE -100, even though the database server process is running?

I understand there is no longer support for 5.5 for ANY OS

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

• Windows NT 3.51, 4.0
• Windows 2000 (EBF #2785 or higher)
• Windows XP (EBF #2816 or higher)
• Windows 95, 98, ME (EBF #2785 or higher)

[johnsmirnios]

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.

[Breck_Carter]

How long does 5.5 run after you start it? In my experience, a few minutes tops, even if idle.

[former_SQLA_member1694870]

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?

[Breck_Carter]

Yes, new questions should always be posted separately... this is primarily a Q&A site, discussions are secondary.

[johnsmirnios]

I left it running all weekend -- it's still going.

[former_SQLA_member1694870]

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.

[former_SQLA_member1694870 · Accepted solution]

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.

[Breck_Carter]

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.

[former_SQLA_member1694870]

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.

[Breck_Carter]

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.

[former_SQLA_member1694880]

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.

[former_SQLA_member1694870]

Agree. 5.5 will be used temporarily in the new 64-bit boxes (if it loads and stay connected of course!!)

[reimer_pods]

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.