RE: [PHP-DB] odbc_columns()
Scott, odbc_columns can take a lot of arguments, but the only one you need to pass is a connection id. It'll return a result identifier containing lots of info on your field names: $conn_id = odbc_connect($dsn, $usr, $pwd) or die (odbc_error()); $result_id = odbc_columns($conn_id) or die (odbc_error()); odbc_result_all($result_id); Best regards, Andrew Hill Director of Technology Evangelism OpenLink Software http://www.openlinksw.com Universal Data Access & Data Integration Technology Providers > -Original Message- > From: Scott Teglasi [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 29, 2002 9:01 PM > To: [EMAIL PROTECTED] > Subject: [PHP-DB] odbc_columns() > > > Hi. Have a question: > > I've tried using the odbc_columns() function to get a list of > columns in an > access database connected via an ODBC System DSN.. However, I haven't had > much luck in trying to use it. The manual page doesn't really cover much > about it, and I noticed a few comments posted there (on www.php.net) > mentioning that it was a pretty badly documented function. > > In any case, there were notes on how to use it with MS SQL 7, but none on > just plain access databases. > > All I want to get is a list of field names in a table. What would the > proper syntax be to do that? > > Any help would be appreciated. > > Thanks, > > Scotty > > > > > -- > 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-DB] odbc_columns()
Hi. Have a question: I've tried using the odbc_columns() function to get a list of columns in an access database connected via an ODBC System DSN.. However, I haven't had much luck in trying to use it. The manual page doesn't really cover much about it, and I noticed a few comments posted there (on www.php.net) mentioning that it was a pretty badly documented function. In any case, there were notes on how to use it with MS SQL 7, but none on just plain access databases. All I want to get is a list of field names in a table. What would the proper syntax be to do that? Any help would be appreciated. Thanks, Scotty -- 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-DB] odbc_columns() help
Hi, Does anyone manage to get odbc_columns(). If you so, can you give me an example, what version of PHP you are using? I've tried various combination of odbc_columns() and never get it to work. Any help would be greatly appreciated. Thank you, --kent -- 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]
RE: [PHP-DB] odbc_columns problem with MSSQL
BDY.RTF -- 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-DB] odbc_columns problem with MSSQL
I am trying to get the column names of some tables with odbc_columns from MSSQL 2000. As I extract a particular column from the result set, the browser hangs. -- 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-DB] odbc_columns()
Yo ho hoodbc_columns() on DB2! Now, it returns a resource ID, as expected but you cannot call odbc_fetch_row() on it or it'll segfault. Hmm.. I filled out a report on this, since I cracked open the php_odbc.c file and verified that all the data's coming back from DB2, and that the bindcols() method is working. After more playing, I still cannot seem to actually USE the results of an odbc_columns() call on DB2 since just about everything "fetch-related" segfaults. Is there another method or set of methods that I'm missing? Thoughts? Ideas? -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]
RE: [PHP-DB] odbc_columns() and DB2
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. Oky. So now > >> we run a SQLGetDiagRec() and look at the SQLSTATE. Okay, > >> here we go! It'sum 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(); >
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. Oky. So now >> we run a SQLGetDiagRec() and look at the SQLSTATE. Okay, >> here we go! It'sum 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 t
RE: [PHP-DB] odbc_columns() and DB2
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. Oky. So now > we run a SQLGetDiagRec() and look at the SQLSTATE. Okay, > here we go! It'sum 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 exam
[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. Oky. So now we run a SQLGetDiagRec() and look at the SQLSTATE. Okay, here we go! It'sum 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]