Okay, here's the problemo.
I make a connection to the DB2 database, and run an
odbc_tables() call on it. No problem. I run an odbc_columns()
on it just fine. Now I call a SECOND odbc_columns() (on a
different table) and get a SIGSEGV and a core dump. *blink*
I cracked open php_odbc.c and put some tracing code in. The
SQLColumns() call returns a column count of -18- (which is too
many anyways) and returns code 100. Okaaaay. So now
we run a SQLGetDiagRec() and look at the SQLSTATE. Okay,
here we go! It's....um....0000 I'll also SIGSEGV if I put in any
SQLFetch() calls. Obviously the SQLColumns() call is not working
correctly, and the 18 is just random (but consistant) memory.
odbc_columns($link,"","",$tablename,"");
odbc_columns($link,"","",$tablename);
They both eval to the same thing in the C code, and they both cause
SIGSEGV. $tablename is valid, as is the resource. I tried odbc_connect()
and odbc_pconnect() with no avail (although I DID notice that the resource
IDs were the SAME for odbc_connect() and varied for odbc_pconnect() with
seems backwards to me.)
Also, if you "mess up" either odbc_columns() or odbc_tables() calls
you'll SEGV as well.
This is against IBM DB2 v7.1 running under Linux. I can make queries
and run "plain SQL" against it without any problems. I'd post my PHP version
but our ISP blows and our SmartJack isn't very smart so I can't access it
right now. It's 4.0.4something and pulled down/built about 7-10 days ago.
With the T1 being down, I can't get access to newer builds, so these problems
may have already been addressed. That should change tomorrow. (*sigh*
Silicon Valley California and we can't keep either our T1s or our power up.
How
very ironic.)
The other "scary" part is in my php code. I have a loop that does,
effectively
this, in pseudo code...
$result = odbc_tables();
$counter = 0;
while (odbc_fetch($result) > 0)
{
Get a column name
Run odbc_columns() on it
$counter++;
}
echo $counter;
Spooky part is, and I've pinned it down to the odbc_columns() calls,
$counter always ends up as -120! Now, if I add one line, right below the
$counter++; line, like so....
$result = odbc_tables();
$counter = 0;
while (odbc_fetch($result) > 0)
{
Get a column name
Run odbc_columns() on it
$counter++;
echo $counter; // <---- new string here
}
echo $counter;
Suddenly $counter comes out to +20, which is correct. If I do NOT add the
extra echo line but DO comment out the odbc_columns() call I get the
correct +20 as well. It's not a scoping issue...nothing "should" change by
adding in an echo...
Memory overwrite that's compensated by the "echo..." line (padded like
a debug build?)
I'm going to keep trying to trace it, but if anyone's heard/seen such oddities
before or has any idea what's going on please drop me a line. The next level
is the ODBC wrapper around the DB2 CLI calls...maybe something odd
happening in there. Anyone have any hints where that level is?
Oh, one final touch - if I odbc_result_all() the first odbc_columns()
result, I
get a whole lot of what looks to be random strings. I can see parameter
lists where there should be names or schemas for example.
Again, it looks like random memory. If SQLColumns() is failing though,
when the bindcols() method is called it'll bind random stuff, so it's not
terribly unexpected.
Does PEAR use these same libraries, or is it a newer more robust
implementation?
Thanks in advance..
-Szii
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
