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 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]
