In order to post questions, answers, or comments, you now need a validated email address. Details on how to validate your address are in the FAQ.

Hello, I have SQLAnywhere 12 installed on a computerA, and I need to make ODBC connection from computerB. Do I need to install SQLAnywhere 12 on computerB as well so that I can make ODBC profile for SQLANywhere 12. Or is it possible to install only ODBC driver on computerB. If it is possible, from where I can download the driver? I am using windows 7 on both computers and SQLAnywhere 64bit. Thanks.

asked Apr 19 '12 at 09:06

sam's gravatar image

sam
315131624

edited Apr 19 '12 at 14:28

Volker%20Barth's gravatar image

Volker Barth
22.2k220331480


You can download a 'client install' from http://www.sybase.com/detail?id=1087327. Distribution of these files is subject to your licensing agreement with Sybase.

answered Apr 19 '12 at 09:38

Mark%20Culp's gravatar image

Mark Culp
18.2k9109212

edited Apr 19 '12 at 12:29

Jeff%20Albion's gravatar image

Jeff Albion
9.0k166149

Thanks for the reply, I installed that on client computer, where my web application is installed (which connects to the database server with ODBC). I created the System DSN and checked connection, it connects successfully, but the web application gives this error: ERROR[08001][Sybase][ODBC Driver][SQL Anywhere] Unable to start database server. PS. The web application does not give this error if I install the SQLAnywhere which comes with the PowerBuilder package. How can I make the Client version to work?

(Apr 20 '12 at 01:23) sam
Replies hidden

What is your connection string - it sounds like you are specifying a DBF parameter and insufficient other parameters to connect to the server?

(Apr 20 '12 at 01:35) Mark Culp
Comment Text Removed

The problem is if I install SQLAnywhere client, the 64-bit ODBC does not connect. If I test connection in ODBC, I get error: 'Unabl to start database server', but the 32-bit ODBC works fine. If I install standard SQLAnywhere, then the 64-bit ODBC connects. So, I would like to know why SQLAnywhere Client version does not connect? If I need 64-bit, do I need to use the standard SQLAnywhere or there's still way to make client version work? Thanks.

(Apr 20 '12 at 02:59) sam
Replies hidden

When you make a connection from machine B to a database running on machine A, the database on A must already be running, and in the connection properties on B, you usually just identify the database by specifying DBN, ENG/SERVER (or HOST for v12), and the credentials - cf. this doc page.

So it might help if you supply the connection parameters you are testing with, as Mark has suggested:)

(Apr 20 '12 at 03:14) Volker Barth

The database is running on machineA, I have installed Anywhere Client 64-bit version on machineB. Now I made a system DSN in ODBC, and supplied the host name, database name etc in the ODBC profile, and clicked to 'Test Connection' with the ODBC interface, and it will say unable to 'Unable to start database server'. If I install 32-bit ODBC, and keep the exact same ODBC profile, and test connection, it will connect. So my application is not involved at all, I'm testing connection with ODBC interface, and same DSN profile will work with 32-bit ODBC but not with 64-bit.

(Apr 20 '12 at 03:38) sam
Replies hidden

When you say "I made a system DSN in ODBC" do you mean a 64-bit system DSN or a 32-bit system DSN (System DSNs have bitness, unlike User DSNs)?

(Apr 20 '12 at 11:43) JBSchueler

...or would it be more appropriate to tell User DSNs have a bitness, as well, but somehow magically they get synchronized between 32-bit and 64-bit? (AFAIK, they still appear under the according 32-bit/64-bit reg hives...)

(Apr 20 '12 at 12:07) Volker Barth

@JBSchueler I meant if I install SQLAnywhere Client edition and create a 64-bit System DSN on 64-bit Windows 7 machineB, it won't connect to the running database on 32-bit Windows XP MachineA . But if create a 32-bit ODBC on machineB, it will connect to the database using same profile. Now, if I install the standard SQLAnywhere (not the client version) on the same machineB, then the 64-bit ODBC will connect as well. So I am unable to understand why 64-bit ODBC will not connect if I install Client version.

(Apr 20 '12 at 13:58) sam
Replies hidden

Please set LogFile on the Advanced tab to a (unique) filename for each of the 32 bit working DSN and the 64 bit failing DSN and post the contents of the files generated after running a test connection. Also, please post the engine start line for the running engine on MachineA. It might be helpful if you were able to add -z (and -o <filespec> ) if not already on the server and post its contents also.

If you have concerns with posting those logs here, you can send them to me by email using this address: <lastname>@sybase.com

(Apr 20 '12 at 14:24) Chris Keating

I think we're still confused as to what you're actually trying in your DSN settings. Both 64-bit and 32-bit ODBC drivers should be able to connect to a remote 64-bit (and 32-bit) database server. The fact that you see the error 'Unable to start database server' sounds like you may have a configuration issue in your DSN information (since this error appears when we have received client information to try to auto-start a local server, not connect to a remote server).

So I am unable to understand why 64-bit ODBC will not connect if I install Client version.

The client install has two versions included - the 32-bit and 64-bit components. Are you trying to just install the 32-bit components, perhaps?

You may find it helpful to dump the ODBC registry contents and compare them across machines to see if the ODBC driver is successfully installed/registered/configured the same in both cases (also see: http://www.sybase.com/detail?id=1091419 ):

regedit /e system_x64.reg HKEY_LOCAL_MACHINE\Software\ODBC
regedit /e system_x86.reg HKEY_LOCAL_MACHINE\Software\Wow6432Node\ODBC
regedit /e user_x64.reg HKEY_CURRENT_USER\Software\ODBC
regedit /e user_x86.reg HKEY_CURRENT_USER\Software\Wow6432Node\ODBC

Can you post the contents of the output from 'dbdsn' to see which DSNs are currently installed on the systems and how they're configured? (Being careful to remove database passwords?)

for /F "skip=2" %i in ('%SQLANY12%\bin32\dbdsn -lu') do "%SQLANY12%\bin32\dbdsn" -gu %i > sa_odbc_x86_user.txt
for /F "skip=2" %i in ('%SQLANY12%\bin32\dbdsn -ls') do "%SQLANY12%\bin32\dbdsn" -gs %i > sa_odbc_x86_system.txt
for /F "skip=2" %i in ('%SQLANY12%\bin64\dbdsn -lu') do "%SQLANY12%\bin64\dbdsn" -gu %i > sa_odbc_x64_user.txt
for /F "skip=2" %i in ('%SQLANY12%\bin64\dbdsn -ls') do "%SQLANY12%\bin64\dbdsn" -gs %i > sa_odbc_x64_system.txt
(Apr 20 '12 at 14:52) Jeff Albion

For System DSNs, the Windows registry has both 32-bit and 64-bit branches (they are in HKEY_LOCAL_MACHINE). Not so for User DSNs (they are in HKEY_CURRENT_USER).

(Apr 20 '12 at 17:02) JBSchueler

Run these commands on the command line(where my-dsn is your DataSourceName and path-to-my-install is exactly that):

path-to-my-install\bin64\dbdsn -gs "my-dsn"

path-to-my-install\bin32\dbdsn -gs "my-dsn"

Do they show exactly the same settings?

Also, try the Test Connection buttons in the 64-bit and 32-bit ODBC Datasource Admins (odbcad32).

PS. I see that Jeff posted below an elegant way to dump your DSNs.

(Apr 20 '12 at 17:12) JBSchueler

A correct configuration of ASA odbc DSN will not "try to start the database". Perhaps you have done a wrong config for the DSN.

Just give you a simple example: dbdsn.exe -y -ws aaa -c "Driver=SQL Anywhere 12;links=tcpip(host=machineB;port=5600;DoBroadCast=NONE;Verify=NO);dbn=ttt;"

will create a DSN connect to 5600 on machineB for the database name ttt. And the dsn name is "aaa".

If you are running 32bit dbdsn.exe, it will create a 32bit odbc DSN. Otherwise, it will create a 64bit odbc DSN.

(Nov 22 '13 at 22:28) Xiong He
More comments hidden
showing 4 of 13 show all flat view

Another alternative is to create a deployment with the Deployment Wizard tool. That's particularly useful IMHO if you only need small client libraries like ODBC or OLEDB, as the mentioned "Client Install" comprises the admin tools, too, and therefore contains a full JRE and the like.

More on these differences can be found in this forum, e.g. in this FAQ.


Of course when creating and applying a deployment you'll have to consider the license restrictions:)

answered Apr 19 '12 at 14:26

Volker%20Barth's gravatar image

Volker Barth
22.2k220331480

edited Apr 19 '12 at 14:27

Your answer
toggle preview

Are you providing an answer to the original question, or making a comment on the question or an answer? If you are making a comment please do not post a new answer. Click "Add new comment" on the question or answer instead. If you are responding to a previous comment, click on the "reply" icon (    ) for that comment.

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link: [text](http://url.com/ "title")
  • image: ![alt text](/path/img.jpg "title")
  • numbered list (indent for sublists):
    1. Foo
    2. Bar
  • bullet list (indent for sublists):
    * Foo
    * Bar
  • to add a line break, add two spaces to where you would like the new line to be.
  • Code blocks should be indented by 4 spaces. SQL code should begin with ":::SQL" on the first line.
  • basic HTML tags are also supported

Tags:

×98
×96
×33
×26

Asked: Apr 19 '12 at 09:06

Seen: 7,069 times

Last updated: Nov 22 '13 at 22:28

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link: [text](http://url.com/ "title")
  • image: ![alt text](/path/img.jpg "title")
  • numbered list (indent for sublists):
    1. Foo
    2. Bar
  • bullet list (indent for sublists):
    * Foo
    * Bar
  • to add a line break, add two spaces to where you would like the new line to be.
  • Code blocks should be indented by 4 spaces. SQL code should begin with ":::SQL" on the first line.
  • basic HTML tags are also supported