Regarding the wrapper - I assume you are using the built-in unified-odbc... which isn't really ODBC. As I understand it unified-odbc is just a common function set as a minimal abstraction to several databases whose syntax calls are fairly similar. Have you tried a 'real' ODBC layer? e.g. compile iODBC driver manager in and drop in some drivers? iODBC is available at www.iodbc.org. Drivers are availabe at www.openlinksw.com Let me know if you require assistance here. If this is NOT unified-odbc, then you can prob. trace the ODBC API calls. Typically the driver manager does this, so you will need to make an addition to the odbc.ini depending on the driver manager. Best regards, Andrew ---------------------------------------------------- Andrew Hill Director Technology Evangelism OpenLink Software http://www.openlinksw.com XML & E-Business Infrastructure Technology Provider > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 19, 2001 1:59 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [PHP-DB] odbc_columns() and DB2 > > > 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 Database 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] > > -- 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]
