Yeah, I'm using the Unified ODBC. The abstraction layer over DB2's CLI is faster than "real" ODBC. -Szii At 08:57 AM 1/19/01 -0500, Andrew Hill wrote: >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]
