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
