cancel
Showing results for 
Search instead for 
Did you mean: 

JDBC access SQL Anywhere 16 not working via Windows Task Scheduler

0 Kudos
2,528

Hello everybody,

we have strange issue. We wrote a Java program that is using JDBC to update and insert data into a SQL Anywhere 16 db running on the same local Windows Server 2008 RT2 as the program itself.

This program should run scheduled every hour - for that, we used the Windows Task Scheduler and created a job there.

When we execute the program on the command line, it works perfectly. However when the task scheduler starts it, Java can not find the server and it runs into an exception:

java.sql.SQLException: [Sybase][JDBC Driver][SQL Anywhere]Database server not found
at sybase.jdbc4.sqlanywhere.IDriver.makeODBCConnection(Native Method)
at sybase.jdbc4.sqlanywhere.IDriver.connect(IDriver.java:811)
at java.sql.DriverManager.getConnection(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at com.mscmobile.mobilink.sap.connector.GenericSAPMobilinkBridge.move(GenericSAPMobilinkBridge.java:1546)
at com.mscmobile.mobilink.sap.connector.GenericSAPMobilinkBridge.moveZODB_SPLUSUSER(GenericSAPMobilinkBridge.java:282)
at com.mscmobile.mobilink.sap.connector.SAPMobiLinkReplicator.main(SAPMobiLinkReplicator.java:55)

This is our connection string: jdbc:sqlanywhere:Server=geaodb;DBN=geaodb;UID=;PWD=;LINKS=TCPIP,SHMEM

We played around with the connection string, but nothing changed this behaviour.

Did anyone else encountered such an issue? Any idea how to solve this?

Thanks for your help and best regards, Alex

Accepted Solutions (0)

Answers (1)

Answers (1)

Is the database server running as a service or running in a foreground session?

If you are running the JDBC client in session 0 as local system, it won't be able to connect over shared memory to a database server running in a regular user session.

Running the database engine/server as a service should allow the connection over shared memory connection to succeed.

Alternatively, you could connect over TCPIP by ensuring LINKS=TCPIP is in the connection string and the server (dbsrv16) not the engine (dbeng16) is being used. This should work regardless of what session the client and server are running in.

Further info on DCX

0 Kudos

Hello Mikel,

you are right, DB Server was started via Sybase Central. After running it as a service, everything worked fine.

Thanks for your help and best regards, Alex

VolkerBarth
Contributor
0 Kudos

Just for the record: As Alexander has originally specified the LINKS connection parameter with TCP/IP in the client's connection string, should that not suffice to reach the local engine (unless the engine itself did not listen on TCP/IP, apparently...)?

Yes, the server should be discovered fine using the UDP broadcast (assuming no -sb 0). Sybase Central starts a dbengXX process when auto-starting the database on connect, so that's possibility what happened here.