Re: [PHP] ODBC and long text fields
- From: jochem@xxxxxxxxxxxxx (Jochem Maas)
- Date: Mon, 08 Jan 2007 03:26:51 +0100
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.
- Follow-Ups:
- Re: [PHP] ODBC and long text fields
- From: Larry Garfield
- Re: [PHP] ODBC and long text fields
- References:
- ODBC and long text fields
- From: Larry Garfield
- ODBC and long text fields
- Prev by Date: Re: Syntax Error
- Next by Date: Re: [PHP] Syntax Error
- Previous by thread: ODBC and long text fields
- Next by thread: Re: [PHP] ODBC and long text fields
- Index(es):
Relevant Pages
|
