Szii

I suggest you test it.  You will discover that the opposite is usually true.

Also, you may have discovered other reasons why Unified ODBC does not
fulfill the value of ODBC.

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 12:58 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: [PHP-DB] odbc_columns() and DB2
>
>
> 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]
>
>


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

Reply via email to