ASA8 DB Identity crisis ONLY from ColdFusion

[former_SQLA_member1694906]

So I've got ASA8 running on a server and it has 2 databases - dmcc and rtm

If I try to connect from ISQL client or from a PHP app to either one, it's fine.

However, if I try connecting from ColdFusion (which connects via JDBC) I am suddenly getting dmcc, whichever datasource I try to connect to. If I shutdown dmcc, then I can connect to rtm, but if I have them both running, then I seem to get no say in which database the connection is to!

I think this is a fairly recent behaviour change. Any ideas what might be going on, and how I might deal with it?

[chris_keating]

It is always best practice to specify both server and database name in connections. Otherwise, connections are being made to the default server and database - which can vary depending on the start order. We certainly have not made changes to ASA8 recently nor do I recall changes in our approach to resolving connections.

If you are not providing both the server and database name in your connection, I would start there. If you continue to have problems, please

1) Describe how you start the database server. Provide any command lines used (masking any sensitive info) 2) Provide the connection string used in Cold Fusion (if this is the only application having problems) 3) Ideally add LOG= to your connection parameters so that a debug log for the connection is created:

 LOG=<file_name_and_path>

[former_SQLA_member1694906]

Thanks Chris.

I'm assuming that this is me not using JDBC quite correctly. The JDBC connection string from the client is jdbc:sybase:Tds:<serveraddress>:2638/rtm6000_m1011

The database name is "rtm6000_m1011" And the server name is "m1011" (although I guess not used, as it's the only one on <serveraddress>)

Does that look correct?

Alex

[former_SQLA_member1694906 · Accepted solution]

OK - that was it! Thanks for focussing my thinking there. It's supposed to be jdbc:sybase:Tds:<serveraddress>:2638?ServiceName=rtm6000_m1011

How silly am I?

[chris_keating · Accepted solution]

I converted your response to an answer.

This is one of several differences in jConnnect behaviour depending on if you are using ASE based and SQL Anywhere based environments. jConnect was designed for use with ASE and required some changes in dealing with some aspects of SQL Anywhere. This is one example. Another relates to autostarting databases which applies only to SQL Anywhere. This uses the RemotePwd mechanism to pass connection parameters to SQL Anywhere.