June 17, 2011 at 8:37 am
I recently added a new table to an existing database. Data is entered into the db via a web front end, using PHP 5. I am not a php developer.
Our developer is trying to build a search query against the new table (there is data in the table). From the page he is working on, he can run a query against any other table in the database, but not against the new table.
I have verified that the user login account he is using has the requisite permissions. I can log in to SSMS with those credentials and runs a select * from the table in question, and it returns all the rows. I can run an osql statement from my desktop and from the developers desktop utilizing the same credentials, and return the rows.
I've run a Profiler trace, and watched while he queries other tables and when he queries the new table. When he queries the "customer" table, which has 161 records in it, I see 485 Reads. When he queries the new table "esb_rt", there are 0 reads.
I think this is a PHP issue. The developer thinks it's a SQL issue. Can anyone provide any ideas where to look that I'm not looking?
June 17, 2011 at 9:20 am
Well, we resolved the issue.
Two of the columns were nvarchar(max) due to SQL DBA's extreme laziness (that's me). Once I throttled that down to a 'mere' 500 each, it worked.
June 17, 2011 at 10:06 am
Just curious because I have supported PHP clients talking to SQL Server...what drivers are the PHP devs using? Is it PHP on Windows or *ix?
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
June 17, 2011 at 1:25 pm
Sorry for the delay in replying...
According to the developer I just asked, it's ix.
June 17, 2011 at 1:44 pm
PHP on *ix talking to SQL Server is a challenge because of the lack of a complete and current open source driver. FreeTDS is the generally accepted "best one" and can do most things but I think it only supports a subset of SQL Server's TDS. You'll have to keep that in mind when planning to work on things using XML columns, Unicode and (as you have seen) MAX data types.
There are some other options that cost $$$ so if you need full functionality then you could look into that.
I have implemented EasySoft ODBC driver and it worked out well for us but PDO would not work with it so we had to move to native ODBC calls in the PHP. It was not desirable but we needed a solution that was guaranteed not to munge data.
The fact is that *ix the developers that maintain the PHP codebase have less motivation to get PHP talking to SQL Server 2008 than fixing bugs talking to MySQL (or just about every other DBMS on the planet).
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
Viewing 5 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply