FreeTDS Development Group

[Neil Whitaker <NWhitaker AT acornstairlifts.com>]

Hi guys,

I have a unix server which has PHP 5.2.13 installed, and it has access to two 
SQL servers (one is running MSSQL SERVER 2000 and the other MSSQL 2005).

It uses FreeTDS - details:
*         Version: freetds v0.91
*         freetds.conf directory: /usr/local/etc
*         MS db-lib source compatibility: no
*         Sybase binary compatibility: no
*         Thread safety: yes
*         iconv library: yes
*         TDS version: 7.1
*         iODBC: no
*         unixodbc: yes
*         SSPI "trusted" logins: no
*         Kerberos: no

And I'm using unixODBC-2.3.1

The MSSQL 2000 server is fine, I can run all SQL statements and use 
mssql_num_rows and mssql_fetch_assoc much as you would with MySQL.

However, the MSSQL 2005 server won't work with mssql_num_rows or 
mssql_fetch_assoc - you have to use odbc_fetch_row.

That's not really an issue, I assume it's just due to the different server 
versions.

However, I have a huge issue with the MSSQL 2005 server connection: I cannot 
select a field AS another name!

For example:

SELECT


   [EnquiryID] AS "The_Key"


   FROM [db].[dbo].[table]


Which works fine in my admin application (ie: NOT PHP), but if I run the same 
in my PHP environment, I get:

stdClass Object


(


    [PK_EnquiryID] => 1


)




You can see it should be [The_Key] => 1

It's reproducible - and I have access to two servers (one with FreeTDS 0.82, 
the other with 0.91) - both exhibit this behaviour.

Before I rewrite all my queries to separate ones, has anyone any idea how I 
can get round this, please? I'm tearing my hair out!

Cheers

Neil
---
www.hencam.co.uk<http://www.hencam.co.uk> - for when you really want to watch 
hens on the Internet...

If you are not the intended recipient, please notify the sender immediately 
by replying to the e-mail, and then delete it without making copies or using 
it in any way. Although any attachments to the message will have been checked 
for viruses before transmission, you are urged to carry out your own virus 
check before opening attachments, since Acorn Stairlifts accepts no 
responsibility for loss or damage caused by software viruses.