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
