ODBC Connection Errors

[tomandrecht]

We have a system that uses ODBC to connect from multiple clients to a SQL Anywhere 16 server machine, where the server machine is simply a database running all the time; sometimes by running the engine with a logged on user, sometimes by running as a service. Now, I'm trying to use a TUniConnection (4.6.12 on Delphi XE3) to connect to this, and am running into trouble. If I have the engine running on the local machine, and ODBC set to "Start and connect to a database on this machine", the rest of the system runs fine (it uses a different old database component), but I cannot connect with my UniDac connection. When I try, I get the error "[Sybase][ODBC Driver][SQL Anywhere]Specified database file already in use." Since nothing else connecting to the running database returns this message, I'm forced to conclude there's something specific to UniDac that is making it try to create a new connection. Is there any way I can have UniDac use the existing running database in these cases?

[AlexP]

Hello,

We can't reproduce the problem on the latest UniDAC version 5.3.10 and SQL Anywhere 16. If the server is set up on a local PC and the ODBC driver is set as "Start and connect to a database on this machine", then UniDAC will connect in both case (to a running server, or will run the server if it is stopped). Please try to reproduce the problem on the latest UniDAC version http://www.devart.com/unidac/download.html and let us know the result.

[tomandrecht]

Ok, I missed mentioning one thing in my original post that I think will make a big difference. My program that uses the UniDac components is a service application. When I try using the components (both versions 4.6 and 5.3) in a Forms app, it works fine, as expected. However, because of the restrictions (mainly, the dialog on start) on the trial 5.3, I cannot test it in a service application.

[tomandrecht]

Issue solved. After further testing, I found it wasn't anything UniDac was doing, but rather the database was trying to force shared memory connections before allowing a TCP/IP connection. I went to the registry, and in the ODBC entry for the database added a string value named "CommLinks" with the value of "TCPIP", which then forced the issue, and allowed the connection through to the database properly, same as it does with the other connection methods. Sorry to trouble you.

[AlexP]

Glad to see that the issue was resolved. If you have any further questions, feel free to contact us.