Re: ODBC and long text fields

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



no real answer, but ...

Larry Garfield wrote:
> Hi all.  I've a question regarding PHP's ODBC support.
> 
> Here's the situation: 
> 
> We've a PHP app that uses ODBC to talk to a MS SQL server.  Its original home 
> was on a server that used the OpenLink ODBC driver, which was a POS, so we 
> build an abstraction wrapper around the subset of PHP's ODBC functions that 
> we were able to use to make it usable.  The internal code for a query is 
> built on odbc_exec, odbc_fetch_row, and odbc_result.  The main interesting 
> part is that the original driver didn't allow for named results, so instead 
> we have a small string parser that reads the incoming SQL query, extracts the 
> field names, and then uses that to map the numeric result indexes to their 
> field name.  Kinda clunky, but worked well and used only a minimal ODBC 
> footprint.  
> 
> That worked fine on their old system.  However, the client then moved from a 
> Windows IIS server to Apache and PHP 5.1.6 on a Linux box, but still talking 
> to an MS SQL server on a Windows box.  We migrated our test environment to 
> the same; Linux/Apache/PHP 5.1 talking to MS SQL on a Windows box over the 
> network.  Our system uses the unix_ODBC and freetds stack for ODBC 
> connectivity, and that works fine.
> 
> On the client's system, it works fine except for a few odd cases.  
> Specifically, on a few queries that pull data from large text fields the 
> query may hang.  It seems to reliably hang on certain records only, and only 
> after those records have been edited.  It seems that when updating a record, 
> there is a small chance of something happening to that record and it then not 
> working thereafter.  A PHP test script run from the command line freezes, 
> while the same query run directly on the SQL server returns almost instantly.

...

> 
> Now I'll be honest and say I don't quite follow what they're talking about. I 
> do not claim to be an ODBC guru, but SQLGetData is a lower-level operation, 
> SQL level or C level I don't know, but not something that happens in PHP code 
> as far as I am aware.  Are they saying there's a bug in PHP's 
> odbc_fetch_row()?  Or is it a bug in their driver if it can't handle whatever 
> it is odbc_fetch_row() does internally?  
> Or should we be using odbc_result() 
> instead of odbc_fetch_row() if we're dealing with a text field rather than a 
> varchar or int?  

the way I read it odbc_result() is just an alternative way of doing what you
do with odbc_fetch_row() - I can't see any reason why doing it with odbc_result()
would suddenly make it work - nonetheless it might be worth trying it just to rule
it out.

with regard to wanting results returned in a 'named' fashion, does the new setup still
not allow use of odbc_fetch_array() instead of odbc_fetch_row()? not that I see any logic
in that solving the issue, again it might be worth trying to see if it does.

I don't know much about MSSQL, or whether 'text' is an actual field type, but maybe
this function offers a wayout?:

	http://php.net/manual/en/function.odbc-binmode.php

are the php versions on the 2 systems you mention exactly the same? (you
mention 5.1 and 5.1.6) this could be a clue to the problem.

lastly I don't suppose that it possible for you to switch to using the MSSQL
specific php extension? [http://php.net/mssql] it might offer a better/faster connection
to the MSSQL server as well as making the issue go away.

> 
> I am confused, and would appreciate assistance in becoming less confused. :-)  
> Thanks.
> 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux