RE: [PHP-DEV] Help talking to iODBC...?

2002-07-25 Thread Andrew Hill 

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 Kalowsky"The 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

RE: [PHP-DEV] php_odbc.c patch

2002-04-08 Thread Andrew Hill 

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

[PHP-DEV] php_odbc.c patch

2002-04-08 Thread Andrew Hill 

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

[PHP-DEV] RE: [PHP-DB] ODBC -- Setting ApplicationID

2002-03-25 Thread Andrew Hill 

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

RE: [PHP-DEV] Re: Solaris and 4.1.2

2002-03-01 Thread Andrew Hill 

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

RE: [PHP-DEV] --with-sybase and --with-ibm-db2 conflict

2002-02-25 Thread Andrew Hill 

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] Suggestion: Wrong-list-link

2002-02-07 Thread Andrew Hill 

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] PHP 4.0 Bug #6645 Updated: Solution to 6572

2002-02-05 Thread Andrew Hill 



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 
  to fetch only the memo field It does not return nothing. 
  Using:PHP 4.1.1(isapi module) , win2000 
  SP2, Openlink ODBC on Visual FoxPro 
  6.0 database. 
   
   
  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] Re: Bug #10369 Updated: Openlink4/ODBC odbc_field_type returns nothing

2001-05-07 Thread Andrew Hill 

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 = , 
*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
> 
> 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:
> >
> > 
> > 
> > Test odbc_field_type
> > 
> >  alink="#FF
> > " marginwidth="0" marginheight="0" topmargin="0" leftmargin="0">
> >  >
> >
> > 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;
>

RE: [PHP-DEV] manual?

2001-03-12 Thread Andrew Hill 

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]

[PHP-DEV] manual?

2001-03-09 Thread Andrew Hill 

Hi gurus,

Who can I bug about the manual?  :) 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.

Thanks in advance.

Best regards,
Andrew
------
Andrew Hill - OpenLink Software
Director Technology Evangelism
eBusiness Infrastructure Technology
http://www.openlinksw.com
office:781.273.0900 x 27
mobile:781.608.4217


-- 
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] PEAR issue #2 (pear-dev) vote

2001-02-22 Thread Andrew Hill 

> [ ] do not change anything
> 
> (X) pear-users and pear-dev
> ( ) pear-general and pear-dev
> 
> [ ] any other idea
>  _
> 


-- 
PHP Development Mailing List 
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] PHP 4.0 Bug #9261: odbc to an oracle 'view' fails

2001-02-14 Thread Andrew Hill 

Hi Andreas,

Generally cursors won't be used with views, as this doesn't make a lot of
sense. :)

That being said, the cursor model in PHP could certainly use some tweaking
to work with cursors.

I'll send you the source code of GTKBench, a GPLed tool we wrote that does
lots of database centric benchmarking tasks.
Among other things it allows testing all the cursor models, so should
provide a good example of the ODBC API implemented with regards to cursors.
Accounting for how GTKBench sets the cursors should give you an idea of how
we are setting cursor parameters in drivers.

Best regards,
Andrew
------
Andrew Hill - OpenLink Software
Director Technology Evangelism
eBusiness Infrastructure Technology
http://www.openlinksw.com




> -Original Message-
> From: Andreas Karajannis [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 14, 2001 2:03 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] PHP 4.0 Bug #9261: odbc to an oracle 'view' fails
>
>
> Andrew Hill wrote:
>
> > Hi,
> >
> > This error indicates that there is no index/primary key in a
> result set that
> > the driver is attempting to read into a cursor.
> > Adding a primary key to the table will fix this, or passing a different
> > cursor type in will fix this - keyset driven cursors are essentially
> > 'sliding windows' - they read a set of rows in, and then scroll back and
> > forth.  Upon reaching the end of the set, they grab the next
> keyset in the
> > direction of scroll.
> >
> > On a related note, does anyone know to pass different cursor
> models in the
> > select statement?  There are essentially 5 cursor models
> supported by SQL,
> > Static, Keyset, Mixed, Forward Scrollable, Bi-Directional Scrollable.
> >
> > PHP's cursor handling has always been a bit of a mystery to me
> - if anyone
> > can point me towards the current implementation of it I will dig.
> >
>
> PHP tries to set the cursor type to Dynamic (or Bi-Directional
> Scrollable) if the driver supports SQLExtendedFetch. If a driver doesn't
> support this cursor model, the next best available model is substituted
> by the driver. This was to enable absolute positing in the resultset
> without bothering the user with choosing a cursor type.
> Unfortunately, there is currently no way to explicitly set the cursor
> type for a statement (I didn't myself really understand the ODBC cursor
> model at that point and was mainly focused on being able to scroll
> through a resultset).
>
> I could add another parameter to odbc_prepare/odbc_exec to set the
> cursor type.
> I'm unsure to what type the cursor should be set, if not specified.
> Either keep the existing behaviour and be backwards compatible or use
> the default static cursor provided.
>
> Any Opinions?
>
> -Andreas
>
> --
> Andreas Karajannis
> mediaworx berlin  AG
>
> Fon (0 30) 2 75 80 - 266
> Fax (0 30) 2 75 80 - 200
>
>


-- 
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] PHP 4.0 Bug #9261: odbc to an oracle 'view' fails

2001-02-14 Thread Andrew Hill 

Hi,

This error indicates that there is no index/primary key in a result set that
the driver is attempting to read into a cursor.
Adding a primary key to the table will fix this, or passing a different
cursor type in will fix this - keyset driven cursors are essentially
'sliding windows' - they read a set of rows in, and then scroll back and
forth.  Upon reaching the end of the set, they grab the next keyset in the
direction of scroll.

On a related note, does anyone know to pass different cursor models in the
select statement?  There are essentially 5 cursor models supported by SQL,
Static, Keyset, Mixed, Forward Scrollable, Bi-Directional Scrollable.

PHP's cursor handling has always been a bit of a mystery to me - if anyone
can point me towards the current implementation of it I will dig.

Best regards,
Andrew
------
Andrew Hill - OpenLink Software
Director Technology Evangelism
eBusiness Infrastructure Technology
http://www.openlinksw.com



> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 14, 2001 9:54 AM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] PHP 4.0 Bug #9261: odbc to an oracle 'view' fails
>
>
> From: [EMAIL PROTECTED]
> Operating system: RedHat Linux 6.1
> PHP version:  4.0.4pl1
> PHP Bug Type: ODBC related
> Bug description:  odbc to an oracle 'view' fails
>
> Hi,
> I' running openlink to an oracle(8.1.5) server. When I try to do
> a 'select' from a view I get the error from PHP:
>
> "Warning: SQL error: [OpenLink][ODBC][Driver]No key columns found
> for table referenced by keyset driven cursor., SQL state IM909 in
> SQLPrepare "
>
> (Using the same driver from Perl works fine)
>
>
>
>
> --
> Edit Bug report at: http://bugs.php.net/?id=9261&edit=1
>
>
>
> --
> 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]
>
>


-- 
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] PHP 4.0 Bug #2934 Updated: Segfault with Openlink

2001-02-13 Thread Andrew Hill 

Please let me know if I can help by testing anything.
I've not received any reports of crashes with OpenLink recently.

Best regards,
Andrew
--
Andrew Hill - OpenLink Software
Director Technology Evangelism
eBusiness Infrastructure Technology
http://www.openlinksw.com
office:781.273.0900 x 27
mobile:781.608.4217

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 13, 2001 2:36 PM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] PHP 4.0 Bug #2934 Updated: Segfault with Openlink
>
>
> ID: 2934
> Updated by: zak
> Reported By: [EMAIL PROTECTED]
> Old-Status: Assigned
> Status: Open
> Bug Type: Reproduceable crash
> Assigned To:
> Comments:
>
>
>
> Previous Comments:
> --
> -
>
> [2000-07-23 02:26:10] [EMAIL PROTECTED]
> Have contacted user to see if problem still occurs with latest
> release of PHP.
>
>
> --
> -
>
> [1999-12-07 18:09:58] [EMAIL PROTECTED]
> I'm getting consistent crashes when trying to connect to an odbc
> data source.  This was occurring with Beta 3, and appears to
> still exist in current CVS code.  I'm somewhat new with this
> backtracing stuff, so hopefully the following is useful.  If not,
> please let me know what I need to do to get a useful backtrace:
>
> # gdb httpd
> GDB is free software and you are welcome to distribute copies of it
>  under certain conditions; type "show copying" to see the conditions.
> There is absolutely no warranty for GDB; type "show warranty" for details.
> GDB 4.16 (powerpc-ibm-aix4.1.4.0),
> Copyright 1996 Free Software Foundation, Inc...
> (gdb) run -X -f /usr/local/www/conf/httpd.conf
> Starting program: /usr/local/www/bin/httpd -X -f
> /usr/local/www/conf/httpd.conf
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xd030d9e4 in ?? () from (unknown load module)
> (gdb) bt
> #0  0xd030d9e4 in ?? () from (unknown load module)
> #1  0xd030d978 in ?? () from (unknown load module)
> #2  0xd04a616c in ?? () from (unknown load module)
> #3  0xd04a6358 in ?? () from (unknown load module)
> #4  0xd04a23b8 in ?? () from (unknown load module)
> #5  0xd04be4e4 in ?? () from (unknown load module)
> #6  0xd045d2d8 in _iodbcdm_driverload ()
> #7  0xd045bf7c in SQLDriverConnect ()
> #8  0x101c83d4 in odbc_sqlconnect (conn=0x2ff20b7c,
> db=0x2017dc70 "DSN=dsn_pro83b", uid=0x0, pwd=0x1000 "
>
> --
> 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]
>
>


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

[PHP-DEV] ODBC and iODBC

2001-02-05 Thread Andrew Hill 

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]

[PHP-DEV] RE: [PHP-DB] odbc_columns() and DB2

2001-01-19 Thread Andrew Hill 

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();
>

[PHP-DEV] RE: [PHP-DB] odbc_columns() and DB2

2001-01-19 Thread Andrew Hill 

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