Re: [PHP-DEV] ODBC Prepare

[Adam Voigt]

Apologies if this was on the wrong list, since the problem was

what I thought was an un-implented feature of the library in PHP's source,

I assumed I should ask the PHP developer's.



I assumed it was un-implemented because I saw no reference to this

ability on the manual page for ODBC or ODBC_Prepare, and PEAR

seems to be doing it with just PHP code (not the odbc_prepare extension).





On Mon, 2003-02-10 at 21:58, Dan Kalowsky wrote:

This is really a support question and is being asked on the wrong list.



But in light of that... PHP's odbc_prepare function should work with 

the '?' option.  It really isn't the one deciding this though, as it's 

more your ODBC Driver.  As far as PEAR is concerned, I have little 

insight into that aspect of PHP.  Your best bet is to ask PEAR 

developers or read the source.



On Monday, February 10, 2003, at 11:48 AM, Adam Voigt wrote:



> According to a manual I found on the web for call's to "SQLPrepare"

> (referenced in ext/odbc/php_odbc.c) you can implant "?" in place of

> variables for statement execution. PearDB makes reference to this

> on:

>

> http://pear.php.net/manual/en/core.db.tut_execute.php

>

> So my question is, is PHP's ODBC programming just not setup to handle

> this (and is Pear doing this manually with PHP) or am I

> mis-understanding

> the way the library works in PHP?

>

> Thanks,

>

> Adam Voigt

> [EMAIL PROTECTED]

>

 >---<

Dan Kalowsky"I've learned to fake it,

http://www.deadmime.org/~dankand just smile along."

[EMAIL PROTECTED]- "Candy",

[EMAIL PROTECTED]  Iggy Pop






-- 
Adam Voigt ([EMAIL PROTECTED])
The Cryptocomm Group
My GPG Key: http://64.238.252.49:8080/adam_at_cryptocomm.asc








signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] ODBC Prepare

[Dan Kalowsky]

This is really a support question and is being asked on the wrong list.

But in light of that... PHP's odbc_prepare function should work with 
the '?' option.  It really isn't the one deciding this though, as it's 
more your ODBC Driver.  As far as PEAR is concerned, I have little 
insight into that aspect of PHP.  Your best bet is to ask PEAR 
developers or read the source.

On Monday, February 10, 2003, at 11:48 AM, Adam Voigt wrote:

According to a manual I found on the web for call's to "SQLPrepare"
(referenced in ext/odbc/php_odbc.c) you can implant "?" in place of
variables for statement execution. PearDB makes reference to this
on:

http://pear.php.net/manual/en/core.db.tut_execute.php

So my question is, is PHP's ODBC programming just not setup to handle
this (and is Pear doing this manually with PHP) or am I
mis-understanding
the way the library works in PHP?

Thanks,

Adam Voigt
[EMAIL PROTECTED]


>---<
Dan Kalowsky"I've learned to fake it,
http://www.deadmime.org/~dankand just smile along."
[EMAIL PROTECTED]- "Candy",
[EMAIL PROTECTED]  Iggy Pop


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] ODBC Prepare

[Adam Voigt]

According to a manual I found on the web for call's to "SQLPrepare"
(referenced in ext/odbc/php_odbc.c) you can implant "?" in place of
variables for statement execution. PearDB makes reference to this
on:

http://pear.php.net/manual/en/core.db.tut_execute.php

So my question is, is PHP's ODBC programming just not setup to handle
this (and is Pear doing this manually with PHP) or am I
mis-understanding
the way the library works in PHP?

Thanks,

Adam Voigt
[EMAIL PROTECTED]

Re: [PHP-DEV] odbc setting boneheadedness? (odbc.defaultlrl)

[Dan Kalowsky]

Setting it to 0 should work.  Or at least it has in the past.

Calling odbc_longreadlen($res_id, ); should also allow you to
override this while running in PHP.  A value of zero again is passthrou.

Any chance you can share a bit more information about this possible bug?


On Mon, 12 Aug 2002, Chuck Hagenbuch wrote:

> Playing with db-based session handlers today against an ODBC database.
> Don't worry, it's not production, but it should work, and now it does...
> except that I had a hell of a time figuring out how to get all of the
> session data, when sessions get large, back from the db server.
>
> I found the odbc.defaultlrl setting pretty quickly, but my first try was to
> set it to 0 - which, I assumed, would mean no limit (like mssql.textsize).
> However, it appears that the comment really does _mean_ "passthru" there.
>
> So, is there any way to set it to a "no limit" value?
>
> -chuck
>
> --
> Charles Hagenbuch, <[EMAIL PROTECTED]>
> "After a few minutes the most aromatic and nice smelling Italian coffee
>  will come out of the exhaustpipe." - Our stove-top espresso pot
>
>

>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] odbc setting boneheadedness? (odbc.defaultlrl)

[Chuck Hagenbuch]

Playing with db-based session handlers today against an ODBC database. 
Don't worry, it's not production, but it should work, and now it does... 
except that I had a hell of a time figuring out how to get all of the 
session data, when sessions get large, back from the db server.

I found the odbc.defaultlrl setting pretty quickly, but my first try was to 
set it to 0 - which, I assumed, would mean no limit (like mssql.textsize). 
However, it appears that the comment really does _mean_ "passthru" there.

So, is there any way to set it to a "no limit" value?

-chuck

--
Charles Hagenbuch, <[EMAIL PROTECTED]>
"After a few minutes the most aromatic and nice smelling Italian coffee 
 will come out of the exhaustpipe." - Our stove-top espresso pot

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] odbc problems in 4.2

[Christoph . Grottolo]

Hi Dan

I've been trying out with the snapshots from snaps.php.net/win32 but I still
have the same errors. The actual snaps of 4.2 don't work either.

Christoph

> I'm looking into these problems right now.  Please be patient.  A recent
> slew of bug reports suggests that there might be some stuff that is
> working for me here locally, but not for other setups..
> 
> As for getting a hold of a different version, the best I can suggest right
> now is A) try a snapshot from http://snaps.php.net/win32 or B) build your
> own (requires VC++, or some such compiler).

> On Fri, 26 Apr 2002, Ryan Jameson (USA) wrote:

> > is this it then? How hard is it to get a hold of a version that is
compiled the same way as my version 4.1.1? I'd really > >like to upgrade. I
do have the tools I need to compile my own version but I'm not set up to do
it and for the last 4 years > >of using PHP I haven't had to since the
distributions have all worked. Thanks.


> Dan Kalowsky wrote:
> > Hi Ryan,
> >
> > Okay did a little looking over the odbc_fetch_row code, and it should
> > reset the result->fetched to whatever the second argument (if one is
> > provided) is.  This variable is how the ODBC result system handles where
> > it currently is in the cache.  Now the catch is that odbc_result checks
> > this value, and if it's set to 0 re-fetches the results.
> >
> This should be perfectly ok, just as if you start with a fresh resultset.
> Row # 0 doesn't contain data.
>
> > So in otherwords the code sample you sent should work, provided that the
> > $rs is a valid result.  I'm having some local DB access/ODBC issues so I
> > cannot test it right at the moment.   I'm working on fixing that.
> >
> >
> >
> > On Wed, 24 Apr 2002, Ryan Jameson (USA) wrote:
> >
> >
> >>If this is easy for anyone could someone verify that:
> >>
> >>odbc_fetch_row($rs,0);
> >>
> >>...does not reset the result set in version 4.2? From what I can tell
> >>it doesn't work at all. I want to be certain that we cannot upgrade to
> >>4.2. If someone has another way to reset an ODBC result set I'd love to
> >>hear about it. It's done in a central core function, but is necessary in
> >>a plethora of scripts. The result set comes from the MS SQL Server
driver
> >>(shhh... I tried to get them to use MySQL ... they are scared of free
> >>stuff. I'm just glad they let me use PHP). Thanks!
> >>
>
> Just to clarify: The odbc module doesn't cache or refetch resultsets.
> Whether you're able to "reset" a resultset depends on the odbc driver
> or driver manager you use (And how PHP was compiled, see below).
> If the driver doesn't support so called "scrollable cursors", some
> Driver Managers (afaik unixODBC and the standard MS Windows DM do)
> provide support for this via a cusror library that caches resultsets and
> emulates scrolling cursors.
>
> My guess is that the PHP 4.2 you've tried was wasn't compiled with
> HAVE_SQL_EXTENDED_FETCH (so only the simple SQLFetch that can only move
> forwards gets used; the rownum parameter is ignored in this case) or that
> your DM wasn't configured to use it's cursor library.
>
> -Andreas
>

RE: [PHP-DEV] odbc problems in 4.2

[Dan Kalowsky]

I'm looking into these problems right now.  Please be patient.  A recent
slew of bug reports suggests that there might be some stuff that is
working for me here locally, but not for other setups..

As for getting a hold of a different version, the best I can suggest right
now is A) try a snapshot from http://snaps.php.net/win32 or B) build your
own (requires VC++, or some such compiler).

On Fri, 26 Apr 2002, Ryan Jameson (USA) wrote:

> is this it then? How hard is it to get a hold of a version that is compiled the same 
>way as my version 4.1.1? I'd really like to upgrade. I do have the tools I need to 
>compile my own version but I'm not set up to do it and for the last 4 years of using 
>PHP I haven't had to since the distributions have all worked. Thanks.
>
> <>< Ryan
>
> -Original Message-
> From: Andreas Karajannis [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 24, 2002 5:16 PM
> To: Dan Kalowsky
> Cc: Ryan Jameson (USA); [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] odbc problems in 4.2
>
>
> Dan Kalowsky wrote:
> > Hi Ryan,
> >
> > Okay did a little looking over the odbc_fetch_row code, and it should
> > reset the result->fetched to whatever the second argument (if one is
> > provided) is.  This variable is how the ODBC result system handles where
> > it currently is in the cache.  Now the catch is that odbc_result checks
> > this value, and if it's set to 0 re-fetches the results.
> >
> This should be perfectly ok, just as if you start with a fresh resultset.
> Row # 0 doesn't contain data.
>
> > So in otherwords the code sample you sent should work, provided that the
> > $rs is a valid result.  I'm having some local DB access/ODBC issues so I
> > cannot test it right at the moment.   I'm working on fixing that.
> >
> >
> >
> > On Wed, 24 Apr 2002, Ryan Jameson (USA) wrote:
> >
> >
> >>If this is easy for anyone could someone verify that:
> >>
> >>odbc_fetch_row($rs,0);
> >>
> >>...does not reset the result set in version 4.2? From what I can tell
> >>it doesn't work at all. I want to be certain that we cannot upgrade to
> >>4.2. If someone has another way to reset an ODBC result set I'd love to
> >>hear about it. It's done in a central core function, but is necessary in
> >>a plethora of scripts. The result set comes from the MS SQL Server driver
> >>(shhh... I tried to get them to use MySQL ... they are scared of free
> >>stuff. I'm just glad they let me use PHP). Thanks!
> >>
>
> Just to clarify: The odbc module doesn't cache or refetch resultsets.
> Whether you're able to "reset" a resultset depends on the odbc driver
> or driver manager you use (And how PHP was compiled, see below).
> If the driver doesn't support so called "scrollable cursors", some
> Driver Managers (afaik unixODBC and the standard MS Windows DM do)
> provide support for this via a cusror library that caches resultsets and
> emulates scrolling cursors.
>
> My guess is that the PHP 4.2 you've tried was wasn't compiled with
> HAVE_SQL_EXTENDED_FETCH (so only the simple SQLFetch that can only move
> forwards gets used; the rownum parameter is ignored in this case) or that
> your DM wasn't configured to use it's cursor library.
>
> -Andreas
>

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

RE: [PHP-DEV] odbc problems in 4.2

[Ryan Jameson (USA)]

is this it then? How hard is it to get a hold of a version that is compiled the same 
way as my version 4.1.1? I'd really like to upgrade. I do have the tools I need to 
compile my own version but I'm not set up to do it and for the last 4 years of using 
PHP I haven't had to since the distributions have all worked. Thanks.

<>< Ryan

-Original Message-
From: Andreas Karajannis [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 24, 2002 5:16 PM
To: Dan Kalowsky
Cc: Ryan Jameson (USA); [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] odbc problems in 4.2


Dan Kalowsky wrote:
> Hi Ryan,
> 
> Okay did a little looking over the odbc_fetch_row code, and it should
> reset the result->fetched to whatever the second argument (if one is
> provided) is.  This variable is how the ODBC result system handles where
> it currently is in the cache.  Now the catch is that odbc_result checks
> this value, and if it's set to 0 re-fetches the results.
> 
This should be perfectly ok, just as if you start with a fresh resultset. 
Row # 0 doesn't contain data.

> So in otherwords the code sample you sent should work, provided that the
> $rs is a valid result.  I'm having some local DB access/ODBC issues so I
> cannot test it right at the moment.   I'm working on fixing that.
> 
> 
> 
> On Wed, 24 Apr 2002, Ryan Jameson (USA) wrote:
> 
> 
>>If this is easy for anyone could someone verify that:
>>
>>odbc_fetch_row($rs,0);
>>
>>...does not reset the result set in version 4.2? From what I can tell
>>it doesn't work at all. I want to be certain that we cannot upgrade to
>>4.2. If someone has another way to reset an ODBC result set I'd love to
>>hear about it. It's done in a central core function, but is necessary in
>>a plethora of scripts. The result set comes from the MS SQL Server driver
>>(shhh... I tried to get them to use MySQL ... they are scared of free
>>stuff. I'm just glad they let me use PHP). Thanks!
>>

Just to clarify: The odbc module doesn't cache or refetch resultsets.
Whether you're able to "reset" a resultset depends on the odbc driver
or driver manager you use (And how PHP was compiled, see below).
If the driver doesn't support so called "scrollable cursors", some
Driver Managers (afaik unixODBC and the standard MS Windows DM do)
provide support for this via a cusror library that caches resultsets and 
emulates scrolling cursors.

My guess is that the PHP 4.2 you've tried was wasn't compiled with 
HAVE_SQL_EXTENDED_FETCH (so only the simple SQLFetch that can only move 
forwards gets used; the rownum parameter is ignored in this case) or that 
your DM wasn't configured to use it's cursor library.

-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, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] odbc problems in 4.2

[Ryan Jameson (USA)]

That sounds possible Andreas, I downloaded the windows binaries from the main site. I 
didn't compile this myself. The first link under Windows Binaries on 
http://www.php.net/downloads.php

... maybe that's all it is, maybe this distribution was compiled differently. As far 
as the driver manager goes, it works fine with 4.1.1 so I'm sure it isn't an issue 
with that.

<>< Ryan

-Original Message-
From: Andreas Karajannis [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 24, 2002 5:16 PM
To: Dan Kalowsky
Cc: Ryan Jameson (USA); [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] odbc problems in 4.2


Dan Kalowsky wrote:
> Hi Ryan,
> 
> Okay did a little looking over the odbc_fetch_row code, and it should
> reset the result->fetched to whatever the second argument (if one is
> provided) is.  This variable is how the ODBC result system handles where
> it currently is in the cache.  Now the catch is that odbc_result checks
> this value, and if it's set to 0 re-fetches the results.
> 
This should be perfectly ok, just as if you start with a fresh resultset. 
Row # 0 doesn't contain data.

> So in otherwords the code sample you sent should work, provided that the
> $rs is a valid result.  I'm having some local DB access/ODBC issues so I
> cannot test it right at the moment.   I'm working on fixing that.
> 
> 
> 
> On Wed, 24 Apr 2002, Ryan Jameson (USA) wrote:
> 
> 
>>If this is easy for anyone could someone verify that:
>>
>>odbc_fetch_row($rs,0);
>>
>>...does not reset the result set in version 4.2? From what I can tell
>>it doesn't work at all. I want to be certain that we cannot upgrade to
>>4.2. If someone has another way to reset an ODBC result set I'd love to
>>hear about it. It's done in a central core function, but is necessary in
>>a plethora of scripts. The result set comes from the MS SQL Server driver
>>(shhh... I tried to get them to use MySQL ... they are scared of free
>>stuff. I'm just glad they let me use PHP). Thanks!
>>

Just to clarify: The odbc module doesn't cache or refetch resultsets.
Whether you're able to "reset" a resultset depends on the odbc driver
or driver manager you use (And how PHP was compiled, see below).
If the driver doesn't support so called "scrollable cursors", some
Driver Managers (afaik unixODBC and the standard MS Windows DM do)
provide support for this via a cusror library that caches resultsets and 
emulates scrolling cursors.

My guess is that the PHP 4.2 you've tried was wasn't compiled with 
HAVE_SQL_EXTENDED_FETCH (so only the simple SQLFetch that can only move 
forwards gets used; the rownum parameter is ignored in this case) or that 
your DM wasn't configured to use it's cursor library.

-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, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] odbc problems in 4.2

[Andreas Karajannis]

Dan Kalowsky wrote:
> Hi Ryan,
> 
> Okay did a little looking over the odbc_fetch_row code, and it should
> reset the result->fetched to whatever the second argument (if one is
> provided) is.  This variable is how the ODBC result system handles where
> it currently is in the cache.  Now the catch is that odbc_result checks
> this value, and if it's set to 0 re-fetches the results.
> 
This should be perfectly ok, just as if you start with a fresh resultset. 
Row # 0 doesn't contain data.

> So in otherwords the code sample you sent should work, provided that the
> $rs is a valid result.  I'm having some local DB access/ODBC issues so I
> cannot test it right at the moment.   I'm working on fixing that.
> 
> 
> 
> On Wed, 24 Apr 2002, Ryan Jameson (USA) wrote:
> 
> 
>>If this is easy for anyone could someone verify that:
>>
>>odbc_fetch_row($rs,0);
>>
>>...does not reset the result set in version 4.2? From what I can tell
>>it doesn't work at all. I want to be certain that we cannot upgrade to
>>4.2. If someone has another way to reset an ODBC result set I'd love to
>>hear about it. It's done in a central core function, but is necessary in
>>a plethora of scripts. The result set comes from the MS SQL Server driver
>>(shhh... I tried to get them to use MySQL ... they are scared of free
>>stuff. I'm just glad they let me use PHP). Thanks!
>>

Just to clarify: The odbc module doesn't cache or refetch resultsets.
Whether you're able to "reset" a resultset depends on the odbc driver
or driver manager you use (And how PHP was compiled, see below).
If the driver doesn't support so called "scrollable cursors", some
Driver Managers (afaik unixODBC and the standard MS Windows DM do)
provide support for this via a cusror library that caches resultsets and 
emulates scrolling cursors.

My guess is that the PHP 4.2 you've tried was wasn't compiled with 
HAVE_SQL_EXTENDED_FETCH (so only the simple SQLFetch that can only move 
forwards gets used; the rownum parameter is ignored in this case) or that 
your DM wasn't configured to use it's cursor library.

-Andreas
-- 
Andreas Karajannis
mediaworx berlin  AG

Fon (0 30) 2 75 80 - 266
Fax (0 30) 2 75 80 - 200



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] odbc problems in 4.2

[Dan Kalowsky]

Hi Ryan,

Okay did a little looking over the odbc_fetch_row code, and it should
reset the result->fetched to whatever the second argument (if one is
provided) is.  This variable is how the ODBC result system handles where
it currently is in the cache.  Now the catch is that odbc_result checks
this value, and if it's set to 0 re-fetches the results.

So in otherwords the code sample you sent should work, provided that the
$rs is a valid result.  I'm having some local DB access/ODBC issues so I
cannot test it right at the moment.   I'm working on fixing that.



On Wed, 24 Apr 2002, Ryan Jameson (USA) wrote:

> If this is easy for anyone could someone verify that:
>
> odbc_fetch_row($rs,0);
>
> ...does not reset the result set in version 4.2? From what I can tell
>it doesn't work at all. I want to be certain that we cannot upgrade to
>4.2. If someone has another way to reset an ODBC result set I'd love to
>hear about it. It's done in a central core function, but is necessary in
>a plethora of scripts. The result set comes from the MS SQL Server driver
>(shhh... I tried to get them to use MySQL ... they are scared of free
>stuff. I'm just glad they let me use PHP). Thanks!
>
> <>< Ryan
>
>

>---<
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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] odbc problems in 4.2

[Robinson, Mike]

Title: RE: [PHP-DEV] odbc problems in 4.2






> -Original Message-
> From: Ryan Jameson writes:


> (shhh... I tried to get them to use MySQL ... they are scared 
> of free stuff. I'm just glad they let me use PHP). Thanks!



Thats a riot.


Tell them to send a cheque to both the MySQL and PHP team for, say,
US$20,000 each, and they can move on unfettered by that fear.


:P 


Mike Robinson
IT/Developer - Torstar Media Group Television
Phone: 416.945.8786 Fax: 416.869.4566
Email: [EMAIL PROTECTED]




To find out more about what we can do for you, please visit us at:
http://www.tmgtv.ca/ and http://www.thestar.com/ 



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] odbc problems in 4.2

[Ryan Jameson (USA)]

If this is easy for anyone could someone verify that:

odbc_fetch_row($rs,0);  

...does not reset the result set in version 4.2? From what I can tell it doesn't work 
at all. I want to be certain that we cannot upgrade to 4.2. If someone has another way 
to reset an ODBC result set I'd love to hear about it. It's done in a central core 
function, but is necessary in a plethora of scripts. The result set comes from the MS 
SQL Server driver (shhh... I tried to get them to use MySQL ... they are scared of 
free stuff. I'm just glad they let me use PHP). Thanks!

<>< Ryan

--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] ODBC limit

[Ling]

Hello there.

Sorry for my post, its out of topic.
I have a question for deveplopers.
is there maximum limit of data ( SQL query ) that can be send via odbc?
I've been exerimenting with inserting large text into database and noticed
that
queries larger than 8190 byte are cause to error:
SQL error: [unixODBC]Requested value changed., SQL state 01S02 in
SQLExecDirect in /path/scriptname
while inserting queries larger than 8190 byte from DataManager ( unixODBC
client ) works just fine.
So, problem looks in PHP.
Of course I may be wrong ( I hope ) and problem can be easily solved.
But I don't know how

OS - RedHat 7.2 ( Enigma )
PHP 4.1.2
ODBC - unixODBC
DB - PostgreSQL 7.2

Thanks
Ling.



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] ODBC-timing issues

[Bruin, Bolke de]

Hi,


(I hope it's the right lists for this)

We're running PHP 4.0.6 on IIS 4.0 as ISAPI module with no trouble so far
in production on a fairly busy website. Though when our database gets
heavily loaded
the script produces an error with "server appears not to be available".
ASP on the same server do not end with such an error.

I scanned the PHP.INI file for settings which could change this behaviour
and to wait
for a connection somewhat longer, but no such luck.

I would like to know if there is a workaround for this and otherwise I would
like to file
it as a bugreport.

If you're wondering where the scripts live

http://www.eurobench.com/guru2.asp

has the applet which request stockquotes and newsheadlines from the
PHP-scripts.
The scripts itself are on 

http://services.eurobench.nl/guru/

try index.php?uid=1001

for an example

thx in advance
Bolke de Bruin

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

[PHP-DEV] ODBC and include() sort of solved (Bug #11969)... (fwd)

[Jani Taskinen]

This was sent to me privately. The problem looks very odd.
Unfortunately I don't have time to look into this any
further right now.

I remember similar thing happening with some pages being reload
twice..some session thingie, that was found out NOT to be bug after all.
I think it was Zeev who closed that report.

--Jani

-- Forwarded message --
Date: Mon, 9 Jul 2001 19:13:58 -0700 (PDT)
From: Thomas Hruska <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: ODBC and include() sort of solved (Bug #11969)...

Well, I tried various things with PHP and finally went back to my web
server's access logs.  Apparently the browser is sending out two requests on
every page, one POST request followed (almost immediately) by a GET request
on form submission pages (my current situation).  The rest of the time the
browser just sends two GET requests.

For now I'll just limit the requests to POST, but people need to be aware of
the issue.  From what I can tell is that if the page takes too long to load,
the browser re-issues the request.

NOTE:  I tested this particular issue with both a custom page retriever that
I wrote as well as testing it with cURL and both retrieved the page just
fine with no duplicate log file entries.  My guess is that the bug is in the
Internet API since both cURL and my code use sockets instead of the API
stuff.  I'm going to go see if re-installing IE helps any (IE contains
kernel updates/fixes).

MacTruck





___
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/



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

[PHP-DEV] ODBC Build

[James Moore]

Can you please look at the patch in bug http://www.php.net/bugs.php?id=10563
and commit it if its needed/comment on the bug.

thanks

- James
--
James Moore
[EMAIL PROTECTED]
http://www.perl.com/search/index.php - we must be doing somthing right



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

[PHP-DEV] ODBC and iODBC

[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 
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 Bugs ...

[phobo]

I dont have a CVS account so cannot touch these ...


Bug 6364; should be a bogus bug?? (you cannot compile PHP with both --iodbc
and with --openlink). http://bugs.php.net/?id=6364


Bug 8089 should be closed (ODBC Error functions now written as of php404).


Just lending a hand,
Siggy :)



- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, February 04, 2001 6:01 AM
Subject: [PHP-DEV] PHP 4.0 Bug Summary Report


> PHP 4.0 Bug Database summary - http://bugs.php.net
>
>  Num Status Summary (1144 total including feature requests)
> ===[*Configuration
Issues]
> 7666 Feedback   PHP4 doesn't read php.ini with NT4/IIS
> 7695 Feedback   Error while accessing php script
> 7774 Open   PHP_AUTH_USER and PHP_AUTH_PW are set when using external
authentication.
> 8238 Feedback   crypt() fails
> 8295 Open   absolute path in extension= directive in php.ini not
recognized
> 8316 Feedback   cannot set short_open_tags to off
> 8670 Open   Incorect interpretation session.gc_maxlifetime parameter
> 8762 Open   No warning when entered nonexistent dll.
> 8815 Open   allow_fopen_url = On & include("URL") don't work
> 8848 Open   "open_basedir = /dir/incl" validates "/dir/include" and so
on
> 9000 Open   echo `cat /etc/passwd` -- bypasses open_basedir .
> 9041 Open   Extra #! at top of web output.
> ===[*Database
Functions]==
> 8706 Open   Database handle corruption?
> ===[*Directory/Filesystem
functions]
> 8564 Open   fread generating false errors
> 8580 Feedback   Fileupload and Database mysql access
> 8698 Open   freediskspace returns zero when used on a windows 2000
'spanned' dynamic drive.
> 9043 Open   popen returns a 'Resource id #' (non null) when process
cannot be created.
> ===[*Function
Specific]===
> 6652 Feedback   include() require() add trailing CRLF
> 6708 Duplicate  Treatment of ' in htmlspecialchars() function
> 6839 Analyzed   get metatags
> 7220 Open   Error Report on Function Arguments
> 8202 Open   exec("java -cp classpath classname inputArgument"); has no
effect
> 8270 Feedback   problem when including phpinfo() command with session
> 8297 Feedback   see test program below
> 8489 Feedback   Function empty() does not work
> 8563 Open   hebrevc() problems...
> 8857 Open   microtime() doesn't work after setlocale(LC_NUMERIC,"pl")
> 8869 Open   phpinfo() returns incorrect Configuration File Path
> ===[*General
Issues]==
> 3076 Analyzed   system and popen are ok in safe_mode, not backquotes
> 4761 Assigned   exec, system all give an error on a fork...
> 6303 Duplicate  make install said libphp4.sl is not a DSO
> 6338 Feedback   script engine
> 6426 Duplicate  system() or exec(): unable to fork
> 6435 Duplicate  can't close session(by session_destroy()) - it write
warning
> 6445 Feedback   problem with opendir
> 6499 Analyzed   $upload_type[] has wrong size with empty multiple-file
uploads
> 6520 Duplicate  session_destroy() does not work
> 6542 Duplicate  exec() and system() cannot fork
> 6617 Open   JVM starts only on 3 requests per httpd
> 6624 Open   error_log() in registered shutdown function
> 6644 Duplicate  Test
> 6685 Analyzed   %20 mis-converted in GET mechanism
> 6875 Duplicate  upload_tmp_dir in php.ini doesn't work in safe_mode
> 6982 Open   disable_functions option don't works in Apache config
> 7134 Duplicate  misbehavior of print and sprintf AGAIN
> 7136 Duplicate  The binary version of php4.0.2 doesn't support the
bindtextdomain function.
> 7243 Duplicate  upload_tmp_dir does not work in safe_mode
> 7444 Duplicate  General reference problems
> 7455 Duplicate  Problems with $this in constructor
> 7525 Duplicate  exec() does not work
> 7626 Feedback   session saving and loading seem to use different locales
> 7685 Open   File Upload Fails with Headers in Unexpected Order
> 7865 Duplicate  exec command
> 8446 Open   PHP/apache process is in infinite loop or appears to suck
CPU
> 8618 Open   httpd process hangs
> 8671 Open   Random "Warning: Failed opening..."
> 9036 Bogus  Non installation of libphp.so
> ===[*Install and
Config]==
> 6614 Duplicate  configure does not recognize sys/socket.h
> 7280 Open   global iniline not supported in SGI Compiler
> 7318 Feedback   libgen.so problems
> 7382 Feedback   Install error on Configuring libtool
> 7731 Open   compilation with deprecated abi (no -n32)
> 7933 Open   install sets dangerous user.group's
> 7959 Open   ld: 0711-317 ERROR: Undefined symbol: .alloca
> 8158 Feedback   unable to find math.h when doing a make
> 8327 Feedback   Son of Defect 4155: X-Powered-By and Content-Type bogus
header

[PHP-DEV] odbc

[André Langhorst]

Hi,
thx to Andreas (module owner), he sent the URLs for this stuff:

general odbc
http://msdn.microsoft.com/library/default.asp?PP=/library/toc/psdk/data/data0-0-3-1-3-1.xml&tocPath=data0-0-3-1-3-1&URL=/library/psdk/dasdk/odch8yed.htm
odbc_statistics()
http://msdn.microsoft.com/library/psdk/dasdk/odch73n8.htm

It would be fine if anyone with DOC karma could add this (these) link(s) 
to help users being confused by all these different odbc parameters...

regards,
andré


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