Our database server was running under ASA 9 and we were connecting from
client computers using the following odbc profile...

[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\albatros s_works]
"Driver"="C:\\Program Files\\Sybase\\SQL Anywhere 9\\win32\\dbodbc9.dll"
"UID"="dba"
"PWD"="*********"
"DatabaseName"="albatross"
"EngineName"="\\\\07-06-tides\\albatross_00"
"AutoStop"="Yes"
"Integrated"="No"
"Debug"="No"
"DisableMultiRowFetch"="No"
"CommLinks"="SharedMemory,TCPIP{},SPX{},NamedPipes "
"Compress"="No"
"Description"="DB"

I recently updated the database server to SQL Anywhere 11. I can connect to
the database on the server itself, but if a client trys to connect using the
following SQL Anywhere 11 odbc profile, I get a "Database server not found"
error.

[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\albatros s_00]
"Driver"="C:\\PROGRA~1\\SQLANY~2\\Bin32\\dbodbc11. dll"
"UserID"="dba"
"Password"="********"
"ServerName"="\\\\07-06-tides\\albatross_00"
"AutoStop"="YES"
"Integrated"="NO"
"Debug"="NO"
"DisableMultiRowFetch"="NO"
"CommLinks"="SharedMemory,TCPIP{}"
"Compress"="NO"
"Description"="DB"
"DatabaseName"="albatross"

I can connect to the server just fine if I use the ASA 9 odbc profile. But
for some reason the SQL Anywhere 11 profile won't work. What am I missing?
I'm using version 11.0.1.2044.

Thanks.

Shenn Sellers

While we sometimes see server names like that
this usage

"EngineName"="\\\\07-06-tides\\albatross_00"

sometimes indicate a flawed configuraton there. When
you start the server, what -n switches do you use?
[in fact show you entire start line or service parameters]

By specifying DEBUG=Yes and LOG=filename.txt
for both you can maybe capture the context of the
way the succeeding connection works and be able to
compare those. [actually debug= is historical and
ignored in both versions I believe, you just need
LOG=filename.txt for it to work]

Also watch our for any asasrv.ini and sasrv.ini
files since they do interact here.



"Shenn Sellers" <ssellers (AT) co (DOT) riverside.ca.us> wrote

Also adding
"a -z -o filename.txt"
to the servers will capture the context
on that side as well.

"Nick Elson [Sybase iAnywhere]" <@nick@.@elson@@sybase@.@com@> wrote in
message news:4aafcbed$1 (AT) forums-1-dub (DOT) ..

Nick,

After looking over the logs and trying things out, I've got it working with
the following configuration.

[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\albatros s_00]
"Driver"="C:\\PROGRA~1\\SQLANY~2\\Bin32\\dbodbc11. dll"
"UserID"="dba"
"Password"="sql"
"ServerName"="albatross_00"
"AutoStop"="YES"
"Integrated"="NO"
"Debug"="NO"
"DisableMultiRowFetch"="NO"
"CommLinks"="SharedMemory,TCPIP{}"
"Compress"="NO"
"Description"="DB"
"DatabaseName"="albatross"

By taking out the computer name , "07-06-tides", under the "ServerName"
entry, that corrected my problem. Was I just doing it wrong this whole time
or did you have to put the computer name in as well using ASA 9? I've been
doing it that way with ASA 9 for years. Maybe SQLAny 11 just makes you do
it the right way now. Thanks for your help.


"Shenn Sellers" <ssellers (AT) co (DOT) riverside.ca.us> wrote

That is consistent with the log from the v9 client trace as well

10:40:55 Attempting TCPIP connection (address 10.20.230.110:2638 found
in asasrv.ini cache)
10:40:55 Trying to find server at cached address 10.20.230.110:2638
without broadcasting
10:40:55 Found server, verifying server name
10:40:55 Found database server at address 10.20.230.110:2638
10:40:55 Found database server albatross_00 on TCPIP link

It seems to just (silently) ignore the prefix with V9.
The fact that it worked before is actually a (silent)
bug I believe. The server name was never meant
to be a system or domain name ... just one known
locally to the dbsrv process internally.


Glad to see you're up and running now

"Shenn Sellers" <ssellers (AT) co (DOT) riverside.ca.us> wrote

It's not so much a bug in v9 as an enhancement in v10, though I suppose
arguments can be made either way. In the version 9 client, we parsed the
server name and if any / or \ characters were found, we interpreted it
as a fully-qualified filename and used the last element of the name
minus the extension as the server name. In this case, we would convert
"ENG=\\\\07-06-tides\\albatross_00" into "ENG=albatross_00", which
explained why it worked. According to the comments in this routine, this
is a hold-over from Watcom SQL version 4, which I believe was released
sometime in the late 1840's.

In v10, we dropped this odd behaviour, so the engine name we searched
for was "\\\\07-06-tides\\albatross_00", which obviously doesn't match
the server's actual name.

Graeme Perrow
Senior Software Developer
gperrow _at_ ianywhere _dot_ com
Sybase iAnywhere Engineering

SQL Anywhere Developer Community
http://www.sybase.com/developer/libr...ere-techcorner
SQL Anywhere Blog Center
http://www.sybase.com/sqlanyblogs


Nick Elson [Sybase iAnywhere] wrote: