FreeTDS + Mssql connector

[tcoates]

Warning: mssql_connect() [function.mssql-connect]: Unable to connect to server: 192.168.53.208 in /opt/lampp/htdocs/mssql-test.php on line 10

Warning: mssql_select_db(): supplied argument is not a valid MS SQL-Link resource in /opt/lampp/htdocs/mssql-test.php on line 11

Warning: mssql_query() [function.mssql-query]: Unable to connect to server: (null) in /opt/lampp/htdocs/mssql-test.php on line 13

Warning: mssql_query() [function.mssql-query]: A link to the server could not be established in /opt/lampp/htdocs/mssql-test.php on line 13


Warning: mssql_fetch_array(): supplied argument is not a valid MS SQL-result resource in /opt/lampp/htdocs/mssql-test.php on line 17


ive looked at my freetds config, anybody have any insight???

[tcoates]

error_reporting(E_ALL);

$sqlhost = "192.168.0.200"; //SQL Server
$sqluser = "sqluser"; //User
$sqlpass = "sqlpass"; //Password
$sqldb = "database"; //Database

$sql_ = mssql_connect($sqlhost, $sqluser, $sqlpass);
$db_ = mssql_select_db($sqldb, $sql_);

$sqlarray = mssql_query("SELECT * FROM tCustomers");

print "<pre>";

while($sqlrow = mssql_fetch_array($sqlarray,MYSQL_ASSOC)){
print_r($sqlrow);
}

print "</pre>";


__________________________________________________
freetds.conf
__________________________________________________

[global]
# TDS protocol version
tds version = 4.2

; initial block size = 512

# uses some fixes required for some bugged MSSQL 7.0 server that
# return invalid data to big endian clients
# NOTE TDS version 7.0 or 8.0 should be used instead
; swap broken dates = no
; swap broken money = no

# Database server login method, if both server and domain
# logins are enabled, domain login is tried first if a domain
# is specified, and if that fails the server login will be used.
# OBSOLETE
; try server login = yes
; try domain login = no

# The default authentication domain, can be overridden by
# specifying a username with a domain prefix, e.g. DOMAIN\username
# OBSOLETE use DOMAIN\username as username
; nt domain = WORKGROUP

# If the server responds with different domain try that one?
# OBSOLETE never been used
; cross domain login = no

# 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 level = 10

# 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.
# (Microsoft servers sometimes pretend TEXT columns are
# 4 GB wide!) If you have this problem, try setting
# 'text size' to a more reasonable limit
text size = 64512

# This is a Sybase hosted database server, if you are directly on the
# net you can use it to test.
[JDBC]
host = 192.138.151.39
port = 4444
tds version = 5.0

# The same server, using TDS 4.2. Used in configuration examples for the
# pool server, since the pool server supports only TDS 4.2.
[JDBC_42]
host = 192.138.151.39
port = 4444
tds version = 4.2

# The client connecting to the pool server will use this to find its
# listening socket. This entry assumes that the client is on the same
# system as the pool server.
[mypool]
host = 127.0.0.1
port = 5000
tds version = 4.2

# A typical Microsoft SQL Server 7.0 configuration
;[MyServer70]
; host = 192.168.53.207
; port = 1433
; tds version = 7.0

# A typical Microsoft SQL Server 2000 configuration
[MyServer2k]
host = ntmachine.domain.com
port = 1433
tds version = 8.0

# A typical Microsoft SQL Server 6.x configuration
;[MyServer65]
; host = ntmachine.domain.com
; port = 1433
; tds version = 4.2




i am trying to connect a php/linux machine with an MSSQL 2000 server running on windows 2003

[tcoates]

is there something i need to rehash besides doing /opt/lampp restart after modifying /opt/lampp/etc/freetds.conf?

[tcoates]

[root@suracell htdocs]# /opt/lampp/bin/tsql -S 192.168.53.208 -p 1433 -U user -P pass
locale is "en_US.UTF-8"
locale charset is "UTF-8"
src/tds/login.c: tds_connect: 192.168.53.208:4000: Connection refused
Msg 20009, Level 9, State 0, Server OpenClient, Line 0
Server is unavailable or does not exist.
There was a problem connecting to the server
[root@suracell htdocs]# /opt/lampp/bin/tsql -S 192.168.53.208:1433 -U user -P pass
locale is "en_US.UTF-8"
locale charset is "UTF-8"
1>




it looks like freetds can make the connection???

[Lisa2004]

1. XAMPP 1.4.6

2. modify php.ini
----enxtension = php_mssql.dll
----extension = mysql.so
3. modify freetds.conf
[global]
tds version = 8.0
initial block dates = 512
swap broken dates = no
swap broken money = no
try server login = yes
try domain login = no
[myserver]
host = ntmachine.domain.com
port=1433
tds version = 8.0

4. Testing
1). Successfully connect to MS SQL server with IP and Port

$ ./tsql -H XXX.XX.XX.XX -p 1433 -U sa
Password:
Msg 5703, Level 0, State 1, Server MyMSServer, Line 0
Changed language setting to us_english.
1>

2). Failed to connect to MS SQL server with domain name

$ ./tsql -S domainName -U sa
Password:
src/tds/login.c: tds_connect: XXX.XX.XX.XX:4000: Connection refused
Msg 20009, Level 9, State 0, Server OpenClient, Line 0
Server is unavailable or does not exist.
There was a problem connecting to the server

Reason: Port 4000 is the compiled-in default for TDS 5.0. The reason FreeTDS is
trying port 4000 is that it's not reading your freetds.conf (or the [domainName] server section doesn't have a 'port' entry).
Unless you used the --prefix= option to the configure script, FreeTDS will look for your file in /usr/local/etc/freetds.conf. It will also
check ${HOME}/.freetds.conf (which might help you in testing, but probably not so good for your PHP server).
You can get a very verbose report of the search for freetds.conf by setting the TDSDUMPCONFIG environment variable.

3). Connected to MS SQL successfully if

$ export TDSPORT=1433
$ ./tsql -S domainName -U sa
Password:
Msg 5703, Level 0, State 1, Server MyMSServer, Line 0
Changed language setting to us_english.
1>

4). Successfully connect to MS SQL 2000 with PHP:

mssql_connect ("domainName:1433", "sa", "XXXXX");
(I have successfully connected to MS SQL 2000 Northwind database and selected
one of the table, but not Orders table.)

mssql_connect ("XXX.XX.XX.XX", "sa", "XXXXX");

Warning: mssql_connect(): Unable to connect to server: XXXX.XX.XX.XX
in ………….. on line 10

5). I have run

$ export TDSDUMP=/etc/freetds.log
but didn’t find freetds.log, don’t why.

6). I have run

$ export FREETDSCONF=/etc/freetds.conf (also tried TDSDUMPCONF)
$ ./tsql -S nomainName -U sa
Password:
src/tds/login.c: tds_connect: XXX.XX.XX.XX:4000: Connection refused
Msg 20009, Level 9, State 0, Server OpenClient, Line 0
Server is unavailable or does not exist.
There was a problem connecting to the server


-------------------------------
Here is my post and reply to freeTDS mailing list, it may help some of you.
FreeTDS@lists.ibiblio.org
---------------------Reply -----
"Lowden, James K" <LowdenJK@bernstein.com> wrote:
Q1. Since We used XAMPP (http://www.apachefriends.org/en/) for our Apach,
PHP, MySQL setting, which has FreeTDS installed and configured by
default.
A1. OK, then you really have to talk to them. See below for the issue.
Q2. How to make freeTDS use freetds.conf instead of bypassing it?
A1: You're not "bypassing" freetds.conf when you're running Apache.
FreeTDS is linked in -- i.e. part of -- the Apache executable. What's
Happening is that FreeTDS is not finding freetds.conf because it's not where it
should be, where "should" is defined by how it was configured when it
was built.

Neither you nor I know what FreeTDS options were used at build time.
If you find that out, you'll know where to put your freetds.conf. Or, at
least, you *can* know. Right now, it's anybody's guess.

Q3. I don't know why there is no TDSDUMP log file (I have run $ export TDSDUMP=/etc/freetds.log ) and why $ export FREETDSCONF=/etc/freetds.conf doesn't work.
A3. I think what you're missing is some basic knowledge about how
Environment variables work. Even though it's a little off-topic here, I'll explain
If you'll bear with me.

When Apache starts, it's running under an account, just as you're
Running under an account when you log in. Whatever variables you set affect
Your session and no one else's, include Apache's. For those variables to
Have any effect on FreeTDS, they have to be set in Apache's session before
it starts. And the account that Apache is running under needs write
access to the file named in TDSDUMP/FREETDSCONF. I point that out because
it's unlikely that the Apache account, 'httpd' or whatever it is, will have
write access to /etc. TDSDUMP=/tmp/freetds.log might be a better
choice.