[freetds] DBD::Sybase not connecting - acts like it is not using FreeTDS

[Darrell Cormier]

I have searched the archives and did not find an answer to my issue.
I have installed FreeTDS 0.91 on a SLES 11 server.
This install works fine because I can connect and query the MS-SQL database (dlus2) using tsql.

As root, I set my SYBASE environment variable to /usr/local:
# echo $SYBASE
/usr/local
since the FreeTDS libs are in /usr/local/lib.
la /usr/local/lib
total 9928
drwxr-xr-x 2 root root 4096 Feb 13 11:56 .
drwxr-xr-x 16 root root 4096 Feb 13 10:58 ..
-rw-r--r-- 1 root root 1995840 Feb 13 11:56 libct.a
-rwxr-xr-x 1 root root 925 Feb 13 11:56 libct.la
lrwxrwxrwx 1 root root 14 Feb 13 11:56 libct.so -> libct.so.4.0.0
lrwxrwxrwx 1 root root 14 Feb 13 11:56 libct.so.4 -> libct.so.4.0.0
-rwxr-xr-x 1 root root 1040101 Feb 13 11:56 libct.so.4.0.0
-rw-r--r-- 1 root root 2189636 Feb 13 11:56 libsybdb.a
-rwxr-xr-x 1 root root 946 Feb 13 11:56 libsybdb.la
lrwxrwxrwx 1 root root 17 Feb 13 11:56 libsybdb.so -> libsybdb.so.5.0.0
lrwxrwxrwx 1 root root 17 Feb 13 11:56 libsybdb.so.5 -> libsybdb.so.5.0.0
-rwxr-xr-x 1 root root 1179261 Feb 13 11:56 libsybdb.so.5.0.0
-rw-r--r-- 1 root root 2376384 Feb 13 11:56 libtdsodbc.a
-rwxr-xr-x 1 root root 996 Feb 13 11:56 libtdsodbc.la
lrwxrwxrwx 1 root root 19 Feb 13 11:56 libtdsodbc.so -> libtdsodbc.so.0.0.0
lrwxrwxrwx 1 root root 19 Feb 13 11:56 libtdsodbc.so.0 -> libtdsodbc.so.0.0.0
-rwxr-xr-x 1 root root 1236836 Feb 13 11:56 libtdsodbc.so.0.0.0
lrwxrwxrwx 1 root root 30 Feb 1 11:28 libtds++.so -> /usr/local/lib/libtds++.so.1.0
-rw-r--r-- 1 root bin 89952 Feb 1 11:28 libtds++.so.1.0
I built the DBD::SYBASE (I tried this with "EXTRA_LIBS= " and "EXTRA_LIBS=-lnsck -lnsl" in CONFIG).
Everything seemed to go fine through the make install.
However, when I attempt a connection to the same server used for the tsql test mentioned above, I get the following message when the statement handle is executed:
DBD::Sybase::st execute failed: Server message number=7202 severity=11 state=2 line=1 server=DLUS2-SQL text=Could not find server 'dlus2' in sys.servers. Verify that the correct server name was specified. If necessary, execute the stored procedure sp_addlinkedserver to add the server to sys.servers. at <path to perl script>/devices.pl line 19.
Can't Execute the shipping data SQL statement: Server message number=7202 severity=11 state=2 line=1 server=DLUS2-SQL text=Could not find server 'dlus2' in sys.servers. Verify that the correct server name was specified. If necessary, execute the stored procedure sp_addlinkedserver to add the server to sys.servers. at <path to perl script>/devices.pl line 19.

I have never experienced this on other Linux installs. Have you experienced this and can you give me an idea why it is looking for the sys.servers rather than using the server config in /usr/local/etc/freetds.conf?

cat /usr/local/etc/freetds.conf

# $Id: freetds.conf,v 1.12 2007/12/25 06:02:36 jklowden Exp $
#
# This file is installed by FreeTDS if no file by the same
# name is found in the installation directory.
#
# For information about the layout of this file and its settings,
# see the freetds.conf manpage "man freetds.conf".

# Global settings are overridden by those in a database
# server specific section
[global]
# TDS protocol version
; tds version = 4.2

# Whether to write a TDSDUMP file for diagnostic purposes
# (setting this to /tmp is insecure on a multi-user system)
; dump file = /tmp/freetds.log
; debug flags = 0xffff

# Command and connection timeouts
; timeout = 10
; connect timeout = 10

# If you get out-of-memory errors, it may mean that your client
# is trying to allocate a huge buffer for a TEXT field.
# Try setting 'text size' to a more reasonable limit
text size = 64512


#Microsoft Manufacturing server
[dlus2]
host = dlus2.<domain>
port = 1433
tds version = 7.0

#Microsoft Test server
[dlus9]
host = dlus9.<domain>
port = 1433
tds version = 7.0


Thanks,
DC

SPAM and Virus prevention by Barracuda Network Solutions

[Darrell Cormier]

I have searched the archives and did not find an answer to my issue.
I have installed FreeTDS 0.91 on a SLES 11 server.?
This install works fine because I can connect and query the MS-SQL database (dlus2) using tsql.

As root, I set my SYBASE environment variable to /usr/local:

# echo $SYBASE
/usr/local

since the FreeTDS libs are in /usr/local/lib.

la /usr/local/lib
total 9928
drwxr-xr-x? 2 root root??? 4096 Feb 13 11:56 .
drwxr-xr-x 16 root root??? 4096 Feb 13 10:58 ..
-rw-r--r--? 1 root root 1995840 Feb 13 11:56 libct.a
-rwxr-xr-x? 1 root root???? 925 Feb 13 11:56 libct.la
lrwxrwxrwx? 1 root root????? 14 Feb 13 11:56 libct.so -> libct.so.4.0.0
lrwxrwxrwx? 1 root root????? 14 Feb 13 11:56 libct.so.4 -> libct.so.4.0.0
-rwxr-xr-x? 1 root root 1040101 Feb 13 11:56 libct.so.4.0.0
-rw-r--r--? 1 root root 2189636 Feb 13 11:56 libsybdb.a
-rwxr-xr-x? 1 root root???? 946 Feb 13 11:56 libsybdb.la
lrwxrwxrwx? 1 root root????? 17 Feb 13 11:56 libsybdb.so -> libsybdb.so.5.0.0
lrwxrwxrwx? 1 root root????? 17 Feb 13 11:56 libsybdb.so.5 -> libsybdb.so.5.0.0
-rwxr-xr-x? 1 root root 1179261 Feb 13 11:56 libsybdb.so.5.0.0
-rw-r--r--? 1 root root 2376384 Feb 13 11:56 libtdsodbc.a
-rwxr-xr-x? 1 root root???? 996 Feb 13 11:56 libtdsodbc.la
lrwxrwxrwx? 1 root root????? 19 Feb 13 11:56 libtdsodbc.so -> libtdsodbc.so.0.0.0
lrwxrwxrwx? 1 root root????? 19 Feb 13 11:56 libtdsodbc.so.0 -> libtdsodbc.so.0.0.0
-rwxr-xr-x? 1 root root 1236836 Feb 13 11:56 libtdsodbc.so.0.0.0
lrwxrwxrwx? 1 root root????? 30 Feb? 1 11:28 libtds++.so -> /usr/local/lib/libtds++.so.1.0
-rw-r--r--? 1 root bin??? 89952 Feb? 1 11:28 libtds++.so.1.0

I built the DBD::SYBASE (I tried this with "EXTRA_LIBS= " and "EXTRA_LIBS=-lnsck -lnsl" in CONFIG).
Everything seemed to go fine through the make install.
However, when I attempt a connection to the same server used for the tsql test mentioned above, I get the following message when the statement handle is executed:

DBD::Sybase::st execute failed: Server message number=7202 severity=11 state=2 line=1 server=DLUS2-SQL text=Could not find server 'dlus2' in sys.servers. Verify that the correct server name was specified. If necessary, execute the stored procedure sp_addlinkedserver to add the server to sys.servers. at <path to perl script>/devices.pl line 19.
Can't Execute the shipping data SQL statement: Server message number=7202 severity=11 state=2 line=1 server=DLUS2-SQL text=Could not find server 'dlus2' in sys.servers. Verify that the correct server name was specified. If necessary, execute the stored procedure sp_addlinkedserver to add the server to sys.servers. at <path to perl script>/devices.pl line 19.

I have never experienced this on other Linux installs.? Have you experienced this and can you give me an idea why it is looking for the sys.servers rather than using the server config in /usr/local/etc/freetds.conf?

cat /usr/local/etc/freetds.conf

#?? $Id: freetds.conf,v 1.12 2007/12/25 06:02:36 jklowden Exp $
#
# This file is installed by FreeTDS if no file by the same
# name is found in the installation directory.?
#
# For information about the layout of this file and its settings,
# see the freetds.conf manpage "man freetds.conf".?

# Global settings are overridden by those in a database
# server specific section
[global]
??????? # TDS protocol version
;?????? tds version = 4.2

??????? # Whether to write a TDSDUMP file for diagnostic purposes
??????? # (setting this to /tmp is insecure on a multi-user system)
;?????? dump file = /tmp/freetds.log
;?????? debug flags = 0xffff

??????? # Command and connection timeouts
;?????? timeout = 10
;?????? connect timeout = 10

??????? # If you get out-of-memory errors, it may mean that your client
??????? # is trying to allocate a huge buffer for a TEXT field.?
????????# Try setting 'text size' to a more reasonable limit
????????text size = 64512


#Microsoft Manufacturing server
[dlus2]
??????? host = dlus2.<domain>
??????? port = 1433
??????? tds version = 7.0

#Microsoft Test server
[dlus9]
??????? host = dlus9.<domain>
??????? port = 1433
??????? tds version = 7.0


Thanks,
DC


SPAM and Virus prevention by Barracuda Network Solutions

[Darrell Cormier]

I have searched the archives and did not find an answer to my issue.

I have installed FreeTDS 0.91 on a SLES 11 server. This install works
fine because I can connect and query the MS-SQL database (dlus2) using
tsql.



As root, I set my SYBASE environment variable to /usr/local:



# echo $SYBASE

/usr/local



since the FreeTDS libs are in /usr/local/lib.



la /usr/local/lib

total 9928

drwxr-xr-x 2 root root 4096 Feb 13 11:56 .

drwxr-xr-x 16 root root 4096 Feb 13 10:58 ..

-rw-r--r-- 1 root root 1995840 Feb 13 11:56 libct.a -rwxr-xr-x 1
root root 925 Feb 13 11:56 libct.la lrwxrwxrwx 1 root root
14 Feb 13 11:56 libct.so -> libct.so.4.0.0 lrwxrwxrwx 1 root root
14 Feb 13 11:56 libct.so.4 -> libct.so.4.0.0 -rwxr-xr-x 1 root root
1040101 Feb 13 11:56 libct.so.4.0.0

-rw-r--r-- 1 root root 2189636 Feb 13 11:56 libsybdb.a -rwxr-xr-x 1
root root 946 Feb 13 11:56 libsybdb.la lrwxrwxrwx 1 root root
17 Feb 13 11:56 libsybdb.so -> libsybdb.so.5.0.0 lrwxrwxrwx 1 root
root 17 Feb 13 11:56 libsybdb.so.5 -> libsybdb.so.5.0.0
-rwxr-xr-x 1 root root 1179261 Feb 13 11:56 libsybdb.so.5.0.0

-rw-r--r-- 1 root root 2376384 Feb 13 11:56 libtdsodbc.a -rwxr-xr-x
1 root root 996 Feb 13 11:56 libtdsodbc.la lrwxrwxrwx 1 root root
19 Feb 13 11:56 libtdsodbc.so -> libtdsodbc.so.0.0.0 lrwxrwxrwx
1 root root 19 Feb 13 11:56 libtdsodbc.so.0 ->
libtdsodbc.so.0.0.0 -rwxr-xr-x 1 root root 1236836 Feb 13 11:56
libtdsodbc.so.0.0.0 lrwxrwxrwx 1 root root 30 Feb 1 11:28
libtds++.so -> /usr/local/lib/libtds++.so.1.0

-rw-r--r-- 1 root bin 89952 Feb 1 11:28 libtds++.so.1.0



I built the DBD::SYBASE (I tried this with ?EXTRA_LIBS= ? and
?EXTRA_LIBS=-lnsck ?lnsl? in CONFIG).

Everything seemed to go fine through the make install.

However, when I attempt a connection to the same server used for the
tsql test mentioned above, I get the following message when the
statement handle is executed:



DBD::Sybase::st execute failed: Server message number=7202 severity=11
state=2 line=1 server=DLUS2-SQL text=Could not find server 'dlus2' in
sys.servers. Verify that the correct server name was specified. If
necessary, execute the stored procedure sp_addlinkedserver to add the
server to sys.servers. at <path to perl script>/devices.pl line 19.

Can't Execute the shipping data SQL statement: Server message
number=7202 severity=11 state=2 line=1 server=DLUS2-SQL text=Could not
find server 'dlus2' in sys.servers. Verify that the correct server
name was specified. If necessary, execute the stored procedure
sp_addlinkedserver to add the server to sys.servers. at <path to perl
script>/devices.pl line 19.



I have never experienced this on other Linux installs. Have you
experienced this and can you give me an idea why it is looking for the
sys.servers rather than using the server config in
/usr/local/etc/freetds.conf?

cat /usr/local/etc/freetds.conf

# $Id: freetds.conf,v 1.12 2007/12/25 06:02:36 jklowden Exp $ # #
This file is installed by FreeTDS if no file by the same # name is
found in the installation directory. # # For information about the
layout of this file and its settings, # see the freetds.conf manpage
"man freetds.conf".



# Global settings are overridden by those in a database # server
specific section [global]

# TDS protocol version

; tds version = 4.2



# Whether to write a TDSDUMP file for diagnostic purposes

# (setting this to /tmp is insecure on a multi-user system) ;
dump file = /tmp/freetds.log ; debug flags = 0xffff



# Command and connection timeouts ; timeout = 10 ;
connect timeout = 10



# If you get out-of-memory errors, it may mean that your client

# is trying to allocate a huge buffer for a TEXT field.

# Try setting 'text size' to a more reasonable limit

text size = 64512





#Microsoft Manufacturing server

[dlus2]

host = dlus2.<domain>

port = 1433

tds version = 7.0



#Microsoft Test server

[dlus9]

host = dlus9.<domain>

port = 1433

tds version = 7.0





Thanks,

D

[James K. Lowden]

On Wed, 13 Feb 2013 19:46:49 +0000
[unwrapping...]

Post by Darrell Cormier
Server message number=7202
severity=11
state=2
line=1
server=DLUS2-SQL
text=Could not find server 'dlus2' in sys.servers. Verify that the
correct server name was specified. If necessary, execute the stored
procedure sp_addlinkedserver to add the server to sys.servers. at
<path to perl script>/devices.pl line 19.

...

Post by Darrell Cormier
I have never experienced this on other Linux installs. Have you
experienced this and can you give me an idea why it is looking for
the sys.servers rather than using the server config
in /usr/local/etc/freetds.conf?

The 7202 message isn't coming from FreeTDS; it's coming from the
server, specifically the server named "DLUS2-SQL".

Whenever you see an error message that includes the name of the server,
you know you're dealing with a server message, not an error from the
library.

Something in your query makes the server think that the string "dlus2"
refers to a server. My guess is your SQL includes something like

execute dlus2.dbname.schema.procname

where you intend "dlus2" to refer to the server running the query, but
it knows of itself as "DLUS2-SQL". It interprets your query as a
remote procedure call, and tries (and fails) to look up "dlus2" among
its named servers in sys.servers.

HTH.

--jkl

[Darrell Cormier]

Post by James K. Lowden
On Wed, 13 Feb 2013 19:46:49 +0000
[unwrapping...]

Post by Darrell Cormier
Server message number=7202
severity=11
state=2
line=1
server=DLUS2-SQL
text=Could not find server 'dlus2' in sys.servers. Verify that the
correct server name was specified. If necessary, execute the stored
procedure sp_addlinkedserver to add the server to sys.servers. at
<path to perl script>/devices.pl line 19.

...

Post by Darrell Cormier
I have never experienced this on other Linux installs. Have you
experienced this and can you give me an idea why it is looking for
the sys.servers rather than using the server config
in /usr/local/etc/freetds.conf?

The 7202 message isn't coming from FreeTDS; it's coming from the
server, specifically the server named "DLUS2-SQL".
Whenever you see an error message that includes the name of the server,
you know you're dealing with a server message, not an error from the
library.
Something in your query makes the server think that the string "dlus2"
refers to a server. My guess is your SQL includes something like
execute dlus2.dbname.schema.procname
where you intend "dlus2" to refer to the server running the query, but
it knows of itself as "DLUS2-SQL". It interprets your query as a
remote procedure call, and tries (and fails) to look up "dlus2" among
its named servers in sys.servers.
HTH.
--jkl
_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

James,
Thanks for that response. Yes, you are correct. The odd thing is that
I copied these perl scripts directly from an old server (configured in
about 2005), which is still running these scripts, and they still work
well. I am wondering if there is a slight change in the newer versions
of DBD::SYBASE that are a little more picky about the server
designation. No matter, I was able to strip all but the table name from
my query statement and it worked well.

Thanks again for the input.

--DC


SPAM and Virus prevention by Barracuda Network Solutions

[James K. Lowden]

On Fri, 15 Feb 2013 09:24:44 -0600

The odd thing is that I copied these perl scripts directly from an
old server (configured in about 2005), which is still running these
scripts, and they still work well. I am wondering if there is a
slight change in the newer versions of DBD::SYBASE that are a little
more picky about the server designation.

Hmm. Maybe. It could be that your query is now executed as a prepared
statement, whereas in 2005 it would have been sent verbatim as plain
SQL. If so, perhaps the server interprets the leading servername
differently in that context.

--jkl

[Frediano Ziglio]

Post by James K. Lowden
On Fri, 15 Feb 2013 09:24:44 -0600

The odd thing is that I copied these perl scripts directly from an
old server (configured in about 2005), which is still running these
scripts, and they still work well. I am wondering if there is a
slight change in the newer versions of DBD::SYBASE that are a little
more picky about the server designation.

Hmm. Maybe. It could be that your query is now executed as a prepared
statement, whereas in 2005 it would have been sent verbatim as plain
SQL. If so, perhaps the server interprets the leading servername
differently in that context.
--jkl

As I remember if you specify the server in the table name the server
must be the name of the server or the name of a linked server. If you
copy the query to another machine which have a different server name
it complaints cause it does not found the table!

This was true even on mssql 2k. That's why you should not specify the
server name for local tables. Probably you where in the wrong database
and you used the table name only then you added the full name
(server.database.owner.tablename) and then when you switch server you
got the problem. If you changed tablename to database..tablename
(owner can be avoided) probably would be enough.

Frediano