[PHP-DEV] 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();
$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
[PHP-DEV] 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 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 PROTECTE
[PHP-DEV] ODBC and iODBC
Gurus, Does it make sense to have the iODBC libraries as part of the standard PHP distribution? This is NOT the OpenLink driver library, but an LGPL Driver Manager. Basically, if php is compiled --with-iodbc then any ODBC API compliant ODBC driver can be used by setting the ODBCINI and ODBCINSTINI environment variables, since iODBC provides a standard ODBC binding point for PHP applications. Much of the work I've done recently to support PHP has been in getting the --with-iodbc configurations working (or --with-openlink for that matter - it's the same thing) and a default inclusion would enable greater use. Also, iODBC includes an SDK, so developers can build their own drivers to compete with OpenLink, Merant, Easysoft, etc. Is bundling/inclusion feasible? Best regards, Andrew Andrew Hill Director Technology Evangelism OpenLink Software http://www.openlinksw.com XML E-Business Infrastructure Technology Provider -- 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]
RE: [PHP-DEV] manual?
I've submitted the change to phpdoc/en/functions/uodbc.xml but I don't have sufficient karma to commit. Anyone want to lend a hand? Best regards, Andrew -- Andrew Hill - OpenLink Software Director Technology Evangelism eBusiness Infrastructure Technology http://www.openlinksw.com -Original Message- From: Jon Parise [mailto:[EMAIL PROTECTED]] Sent: Friday, March 09, 2001 4:34 PM To: Andrew Hill Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] manual? On Fri, Mar 09, 2001 at 04:22:12PM -0500, Andrew Hill wrote: Who can I bug about the manual? :) There's a separate mailing list ([EMAIL PROTECTED]) for manual maintenance. The ODBC page http://www.php.net/manual/en/ref.odbc.php is a little misleading, namely that iODBC is a database, and the subsequent text implies that the unified ODBC functions don't use ODBC when connecting via iODBC, which isn't true. Also, I would like to get some mention of OpenLink on that page. If you could submit a diff against the XML document source (or just reword all of the text), I (or someone else) will submit your changes to the phpdoc cvs tree. -- Jon Parise ([EMAIL PROTECTED]) . Rochester Inst. of Technology http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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]
RE: [PHP-DEV] Re: Bug #10369 Updated: Openlink4/ODBC odbc_field_type returns nothing
Daniel,
I did reproduce your problem, first with both the OpenLink driver and the
SQLServer native driver, and then both with and without PHP (e.g. directly
against SQLServer, making the API calls directly) This problem exists in
the absense of PHP or OpenLink, therefore it's intrinsic to the SQLServer
layer.
If you are interested, here is the evidence of the native driver failing
(looks the same as via ODBC).
SQLColAttributes:
In: hstmt = 0x008218D8,
icol = 1, fDescType = SQL_COLUMN_TYPE=2,
rgbDesc = 0x00154528, cbDescMax = 600, pcbDesc = 0x001552F0,
pfDesc
= 0x00155E30, Description Type = SQL_C_SLONG=-16
Return: SQL_SUCCESS=0
Out:*rgbDesc = unmodified,
*pcbDesc = 4, *pfDesc = 4
TST1001: Buffer rgbDesc was not updated.
Best regards,
Andrew Hill
Director of Technology Evangelism
OpenLink Software http://www.openlinksw.com
Universal Data Access Data Integration Technology Providers
-Original Message-
From: Daniel H. Ardison [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 07, 2001 9:55 AM
To: Bug Database
Subject: [PHP-DEV] Re: Bug #10369 Updated: Openlink4/ODBC
odbc_field_type returns nothing
Firstly, I already compiled with odbc support, as I said it in my mail, I
can retrieve the data but I can't retrieve column SQL Data Type, I have a
case opened with openlink and the last thing they said was:
Daniel,
I tested this using the SQL Server native driver, and the results are the
same as with ours: the SQLColAttributes() ODBC call returns a
unmodified
value for SQL_COLUMN_TYPE. I do not know why this is the case; it would
need to be investigated with Microsoft. The SQLDescribeCol() API call is
much more robust, and will return the information you require.
However, I
don't know if the PHP development community is willing to invest in this
change.
Best regards,
Stephen - Online Support Team
I'm curious, why you decided to close the case without testing?, or if you
tested the script I sent why you don't mentioned, I don't follow your QA.
Thanks anyway
Daniel H. Ardison
Systems Development Manager
Ardison Software Consulting
- Original Message -
From: Bug Database [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Viernes 4 de Mayo de 2001 4:15 PM
Subject: Bug #10369 Updated: Openlink4/ODBC odbc_field_type
returns nothing
ID: 10369
Updated by: ahill
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: ODBC related
PHP Version: 4.0.4pl1
Assigned To:
Comments:
Firstly, please use --with-iodbc instead of --with-iodbc.
Also, this is most likely not a PHP issue but a database specific issue,
and will only occur in cases where the corresponding database CLI call
doesn't work natively.
Please test this with the latest OpenLink drivers and open a
support case
at http://www.openlinksw.com/support/suppindx.htm if the problem persists.
Previous Comments:
--
-
[2001-04-17 20:12:15] [EMAIL PROTECTED]
This script reproduces the problem:
HTML
HEAD
TITLETest odbc_field_type/TITLE
/HEAD
BODY bgcolor=#00 text=#CC link=#33CCFF vlink=#996699
alink=#FF
marginwidth=0 marginheight=0 topmargin=0 leftmargin=0
?php
putenv(LD_LIBRARY_PATH=/usr/local/openlink/odbcsdk/lib);
putenv(LIBPATH=/usr/local/openlink/odbcsdk/lib:$LIBPATH);
putenv(SHLIB_PATH=/usr/local/openlink/odbcsdk/lib:$SHLIB_PATH);
putenv(UDBCINI=/usr/local/openlink/bin/odbc.ini);
putenv(ODBCINSTINI=/usr/local/openlink/bin/odbcinst.ini);
putenv(ODBCINI=/usr/local/openlink/bin/odbc.ini);
$dsn=DSN=Arbant;
$user=dba;
$password=sql;
$sql='Select cod_emp, cod_amb, den from loguec';
if(($conn_id=odbc_connect($dsn,,))){
if(($result=odbc_prepare($conn_id,$sql))){
@odbc_execute($result);
if(!empty($result)){
$cols_count=odbc_num_fields($result);
$ind=1;
while($ind=$cols_count){
$cols_name[$ind]=odbc_field_name($result,$ind);
$cols_types[$ind]=odbc_field_type($result,$ind);
$ind++;
}
echo H1Results/H1;
echo BThe Query is: $sqlBn;
echo 'TABLE align=center border=1 bordercolor=green
cellpadding=
2 cellspacing=0';
$ind=1;
echo trtdbNames/b/tdtdbTypes/b/td/tr;
while($ind=$cols_count){
echo tr;
echo td . $cols_name[$ind] . /tdn;
echo td . $cols_types[$ind] . /tdn;
echo /tr;
$ind++;
}
odbc_free_result($result);
}else{
echo Cannot execute query;
}
}else{
echo Cannot prepare query;
}
}
?
/BODY/HTML
I compiled PHP standard, I
RE: [PHP-DEV] PHP 4.0 Bug #6645 Updated: Solution to 6572
Diego, I suggest you open a support case with OpenLink at http://www.openlinksw.com/support/suppindx.htm Either way, an ODBC trace will be helpful. Uncomment the "DebugFile" line in your odbc.ini and paste the resulting trace into either this bug report one on OpenLink's site. Best regards,Andrew HillDirector of Technology EvangelismOpenLink Software http://www.openlinksw.comUniversal Data Access Data Integration Technology Providers -Original Message-From: Diego Trinciarelli [mailto:[EMAIL PROTECTED]]Sent: Tuesday, February 05, 2002 5:37 AMTo: [EMAIL PROTECTED]Subject: Re: [PHP-DEV] PHP 4.0 Bug #6645 Updated: Solution to 6572 None of the solutions seems to work for me, i cannot open Memo fields.If I try tofetch only the memo field It does not return nothing. Using:PHP 4.1.1(isapi module) , win2000 SP2, Openlink ODBC on Visual FoxPro 6.0database. ID: 6645 Updated by: torben Reported By: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related Assigned To: Comments: I've copied this text into the appropriate bug report (#6572). Previous Comments: --- [2000-09-09 23:41:37] [EMAIL PROTECTED] That should be SQL_CUR_USE_ODBC without the $. --- [2000-09-09 23:31:59] [EMAIL PROTECTED] Bug 6572 claims that MEMO fields cannot be read. Oddly, this also happens in ASP/vbscript, however you can MEMO fields to work correctly with the following: You can get MEMO fields to work. Right now it takes some finesse. #1) You may try adding $SQL_CUR_USE_ODBC #2) You need to use odbc_longreadlen before you use odbc_fetch_row, otherwise it will not read enough characters. #3) As of 4.0.2, making odbc_longread too long may cause PHP to become unstable. #4) You may need to make a query that only returns the MEMO field to read it correctly. Otherwise it sometimes just doesn't work (this is similar in ASP and so is probably a bug with Access or ODBC drivers for it.) Example: $conn = odbc_connect( $DSN, $user, $pw, $SQL_CUR_USE_ODBC ); $result = odbc_exec( $conn, $query ); odbc_longreadlen( $result, 100); /* Your odbc_fetch_row, etc, will now work */ ---
RE: [PHP-DEV] Suggestion: Wrong-list-link
Helmut wrote: anyway, i'd like to know the cause instead of just dealing with the symptoms. a automatic reply link won't be kind, no matter how polite the text it sends is, unless something makes sure the user gets this automatic reply only once per message Well, I don't know what percentages of the valid posts to the php-dev lists are from folks with an @php.net address, e.g. cvs developers, but requiring registration to this list or cvs specifically (with list use suggestions) would cut down on the random post, programming questions, etc. Of course the risk is that this would result in an overall lowering of bug reports. Best regards, Andrew Hill Director of Technology Evangelism http://www.openlinksw.com/virtuoso/whatis.htm OpenLink Virtuoso Internet Data Integration Server -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] --with-sybase and --with-ibm-db2 conflict
Casey, You may wish to try iODBC instead of UnixODBC. I'd also suggest trying OpenLink's Single-Tier ODBC drivers. Best regards, Andrew Hill Director of Technology Evangelism OpenLink Software http://www.openlinksw.com Universal Data Access Data Integration Technology Providers -Original Message- From: Casey Allen Shobe [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 24, 2002 4:46 PM To: Brian Bruns; Rasmus Lerdorf Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] --with-sybase and --with-ibm-db2 conflict On Sunday 24 February 2002 16:16, Brian Bruns wrote: I have both those compiled into my setup at work so I can take a look, we use --with-sybase-ct to work around the issue, I think we also had to make sure that --with-ibm-db2 appeared in the configure line prior to the other. Well, I tried using --with-sybase-ct, but I'm actually using FreeTDS to communicate with MSSQL, and for some reason --with-sybase-ct won't work with the FreeTDS libraries when trying to built PHP following the instructions here: http://www.freetds.org/userguide/php.html#AEN945 The ODBC support is buggy...as in, I can connect to and run queries on both DB2 and MSSQL via isql (comes with unixodbc) on the command line, but via PHP, only DB2 works when I try to use both within a script. -- Casey Allen Shobe [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Solaris and 4.1.2
I believe the Solid config option causes this. Best regards, Andrew Hill Director of Technology Evangelism OpenLink Software http://www.openlinksw.com Universal Data Access Data Integration Technology Providers -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Friday, March 01, 2002 5:29 AM To: [EMAIL PROTECTED] Cc: Max Galvin Subject: [PHP-DEV] Re: Solaris and 4.1.2 Max Galvin wrote: With the security update I've decided to update PHP to 4.1.2. In compiling I have had the following error: In file included from internal_functions.c:32: /install/php-4.1.2/ext/odbc/php_odbc.h:187: WINDOWS.H: No such file or directory /install/php-4.1.2/ext/odbc/php_odbc.h:188: sql.h: No such file or directory /install/php-4.1.2/ext/odbc/php_odbc.h:189: sqlext.h: No such file or directory make[2]: *** [internal_functions.lo] Error 1 make[2]: Leaving directory /install/php-4.1.2/main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/install/php-4.1.2/main' make: *** [all-recursive] Error 1 Does anyone have any clue what causes it? Here's the config I'm using (obviously path/to/Solid is replaced when I run it) ./configure --with-solid=/path/to/Solid --enable-debug=no --without-mysql --without-gd --enable-track-vars ODBC is built by default now? I hope it's not, even if it's listed in internal module array. Someone would like to check this before branching, hopefully. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PHP-DB] ODBC -- Setting ApplicationID
Bruce, It looks like you were on the right track initially, the problem is that PHP has a major bug - odbc_setoption is coded specific to ODBC statement handle (connection id), which means that trying to use odbc_setoption the way you want attempts to set a SQLSetConnectOption AFTER the connection is open - which is bogus and will give you ODBC function sequence errors. On the other hand, the error message you were getting is a bit misleading; we are fixing that now. So... you can unfortunately not do this via Application ID, but since you are using the OpenLink Rules Book, you can still affect Session-based connection management with any of the other connection criteria: Here is one way to do it: -- Setup your session attributes by configuring the Session Rules Book Aliases section of the Multi-Tier OpenLink Admin Assistant. (http://servername:8000). You can configure session rules for any combination of Domain, Database, User, Operating System, Client Machine, Client Application, etc., and can control any connection options at the server side based on the session. Using Database as an example, add a Database Alias with a new database name and configure a session mapping rule to point to the original database name, but change the connection attributes from Read / Write to Read Only in the options for the connection session. On the PHP side, simply choose between two DSN's in the odbc.ini - one is the normal DSN, with default settings, and one will have an alternate database name, name_readonly or somesuch, that will cause the oplrqb to instantiate the appropriate connection attributes. If you run into problems, you should probably open a support case at http://www.openlinksw.com/support/suppindx.htm, as this is getting somewhat off-topic for PHP. Hope this helps! Best regards, Andrew Hill Director of Technology Evangelism OpenLink Software http://www.openlinksw.com Universal Data Access Data Integration Technology Providers I was thinking of using the usernames, but as people come and go, that might mean messing around with the oplrqb.ini file too much. I'd really like to do this based on application. What variable do I pass with the PHP script? ( I'm not sure what you mean ). Can I use a variable in PHP that passes the application name to the server? Thanks, Bruce Andrew Hill wrote: Hi Bruce, The setoption error is being thrown because you cannot use SQLSetConnectOption that way. Passing arbitrary info to be used by your application isn't really what this is for, but instead can be used to modify parameters in the ODBC API. This means you can modify things like SQL_ACCESS_MODE, SQL_AUTOCOMMIT, SQL_ODBC_CURSORS, etc., (check the 2.x spec - there are several metadata items that you can control with this API call.) I'd recommend you just pass a variable to your PHP script, and perhaps change the username to a read-only/read-write user with a case statement or somesuch, based on the application. Again, I'd strongly recommend you upgrade the OpenLink UDA version as well; 1.5 is something like 5 years old or more. Best regards, Andrew Hill Director of Technology Evangelism http://www.openlinksw.com/virtuoso/whatis.htm OpenLink Virtuoso Internet Data Integration Server -Original Message- From: Bruce S. Garlock [mailto:[EMAIL PROTECTED]] Sent: Monday, March 25, 2002 10:48 AM To: [EMAIL PROTECTED] Subject: Re: [PHP-DB] ODBC -- Setting ApplicationID Sure, I'm simply trying to have PHP pass an ApplicationID to the ODBC server. When a PHP script access the ODBC database, it does not set the application: 10:46:04 connectopts= user=webuser opsys=unix machine=linux application= As you can see, application= is NULL. I would like the script to pass something, so that my mapping rules on the server would allow write access to the db, if the PHP application sends a certain name. Currently our Win32 applications, like MS Access, send application names. e.g. Access, sends: application=MSACCESS. Thanks for your help, Bruce Andrew Hill wrote: Bruce, I'm not sure what you are trying to do - could you clarify? You may be able to simply use the OpenLink Rules Book to set role-based authentication on domain, ip, application, etc. Also, the ODBC Driver version (1.5) you are using is _very_ old and unsupported. I suggest you upgrade to 4.2 Best regards, Andrew Hill Director of Technology Evangelism OpenLink Software http://www.openlinksw.com Universal Data Access Data Integration Technology Providers -Original Message- From: Bruce S. Garlock [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 11:02 AM To: [EMAIL PROTECTED] Subject: [PHP-DB] ODBC -- Setting ApplicationID I am trying to set the ApplicationID, when connecting to an ODBC datasource. I have tried: odbc_setoption
[PHP-DEV] php_odbc.c patch
Hi folks, Attached please find a zip file containing both a diff and a modified php_odbc.c file that cleans up some problems with Connection in Use errors our customers (and others) were having with PHP. The patch was made against PHP 4.1.2 Can Dan et. al. check it over and commit please? Best regards, Andrew Hill Director of Technology Evangelism OpenLink Software http://www.openlinksw.com Universal Data Access Virtuoso Universal Server php-odbc-patch.zip Description: application/applefile php-odbc-patch.zip Description: Macintosh archive -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php_odbc.c patch
Hi Dan, Yes, the .diff whitespace change is relevant, as preprocessor codes have to start in the first column. I've asked the iODBC maintainer (who produced this patch) to look at 4.2.0. And these weren't Mac files - should be fine on *nix platforms. Best regards, Andrew Hill Director of Technology Evangelism OpenLink Software http://www.openlinksw.com Universal Data Access Virtuoso Universal Server -Original Message- From: Dan Kalowsky [mailto:[EMAIL PROTECTED]] Sent: Monday, April 08, 2002 1:17 PM To: Andrew Hill Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] php_odbc.c patch Hey Andrew, Dont mind any bad typing by me, I am not used to German keyboard layouts. Your patch .diff file does seem to do anything though except a whitespace change. Is that the proper diff file? Derick the message is a .zip btw. This message took 20 minutes to write... sorry for brevity. On Mon, 8 Apr 2002, Andrew Hill wrote: Hi folks, Attached please find a zip file containing both a diff and a modified php_odbc.c file that cleans up some problems with Connection in Use errors our customers (and others) were having with PHP. The patch was made against PHP 4.1.2 Can Dan et. al. check it over and commit please? Best regards, Andrew Hill Director of Technology Evangelism OpenLink Software http://www.openlinksw.com Universal Data Access Virtuoso Universal Server --- Dan Kalowsky The record shows, I took the blows. http://www.deadmime.org/~dank And did it my way. [EMAIL PROTECTED] - My Way, Frank Sinatra -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Help talking to iODBC...?
Jay, Still having problems? Email me backchannel. Best regards, Andrew Hill Director of Technology Evangelism OpenLink Software http://www.openlinksw.com Universal Data Access Virtuoso Universal Server -Original Message- From: Dan Kalowsky [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 3:11 PM To: Jay Van Vark Cc: PHP Development Mailing list Subject: Re: [PHP-DEV] Help talking to iODBC...? On Mon, 24 Jun 2002, Jay Van Vark wrote: --with-iodbc=/usr/local/src/odbcsdk I have iODBC installed at /usr/local/src/odbcsdk Then that is the proper path to be using. I am trying to get iODBC to connect to a database - I have PHP compiling ok, but it never finds any of the DSNs that I have defined... I can find them in iSQL, but not from PHP... Have you followed the instructions at iodbc.org? You have to define the ODBCINI path in your PHP file for iODBC to work. Andrew Hill has created a good tutorial on doing this at: http://www.iodbc.org/iodbc-phposxHOWTO.html --- Dan KalowskyThe record shows, I took the blows. http://www.deadmime.org/~dankAnd did it my way. [EMAIL PROTECTED] - My Way, Frank Sinatra [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
