phplib-trackers — List for monitoring the phplib SourceForge trackers.

[Phplib-trackers] [ phplib-Feature Requests-577332 ] Template caching

[<no...@so...>]

Feature Requests item #577332, was opened at 2002-07-04 11:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403614&aid=577332&group_id=31885

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Dipl.-Inform. Kai Hofmann (powerstat)
Assigned to: Nobody/Anonymous (nobody)
Summary: Template caching

Initial Comment:
It would be nice to have a kind of template output
caching to speed up template processing. For example
some template outputs will only change in 24 hours or
more.
This will not work for all templates but for a lot it
might bring significant improvement - especially in
combination with php-accelerator.
Maybe it is helpful to take a look at the "Smarty 2.x"
template engine, also please take a look at the
PHP-Accelerator Benchmarks at
http://www.phpinsider.com/benchmarks/


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403614&aid=577332&group_id=31885

[Phplib-trackers] [ phplib-Feature Requests-543468 ] unset_var for template.inc!

[<no...@so...>]

Feature Requests item #543468, was opened at 2002-04-13 21:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403614&aid=543468&group_id=31885

Category: None
Group: None
Status: Open
Priority: 1
Submitted By: Dipl.-Inform. Kai Hofmann (powerstat)
Assigned to: Nobody/Anonymous (nobody)
Summary: unset_var for template.inc!

Initial Comment:
Please add a method unset_var("varname/array") to the template engine.
This is required when handling blocks within blocks!!!!
Because in this situation you have sometime to clear already set variables!
Blocks within blocks can be very power- and helpfull but one ran into strange situations when no 
unset_var is available.
Its 5 Minutes of work or less!

Thanks.


----------------------------------------------------------------------

>Comment By: Dipl.-Inform. Kai Hofmann (powerstat)
Date: 2002-07-04 11:27

Message:
Logged In: YES 
user_id=286352

Sorry to say, but my experience shows that it is not a
simple set_var("name","") because this is different from a
real unset() !

----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2002-04-15 17:13

Message:
Logged In: YES 
user_id=278685

A unset_var() (or clear_var() as I use in my personal 
extension) is simply an alias for set_var("varname", ""). 
Someone may get around to adding such an alias to the 
official library, but it is far less urgent than many 
existing bugs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403614&aid=543468&group_id=31885

[Phplib-trackers] [ phplib-Bugs-474478 ] ac_store.inc and MS-SQL7

[<no...@so...>]

Bugs item #474478, was opened at 2001-10-24 07:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=474478&group_id=31885

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jaros³aw Zabie³³o (zbiru)
Assigned to: Nobody/Anonymous (nobody)
Summary: ac_store.inc and MS-SQL7

Initial Comment:
I changed "val='%s'" to "val like '%'" because MSSQL7 
cannot use variable='values' as a part of WHERE 
subquery. val should be also defined as TEXT, not 
VARCHAR(xxx). Open file ac.store.inc and change

old:

$squery = sprintf("select count(*) from %s where val 
= '%s' and changed='%s' and sid='%s' and name='%s'",

new:

$squery = sprintf("select count(*) from %s where val 
like '%s' and changed='%s' and sid='%s' and name='%s'",


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-07-04 00:14

Message:
Logged In: NO 

Check the date of my first comment: 2001-10-24. The 'val' 
variable was varchar at that time.

----------------------------------------------------------------------

Comment By: Chris Johnson (chaska)
Date: 2002-07-03 13:25

Message:
Logged In: YES 
user_id=279065

What's he saying?  val is defined as TEXT, as far as I can 
tell.  Why would one use LIKE with val, but not with the 
other string variables, changed, sid and name?

----------------------------------------------------------------------

Comment By: Chris Johnson (chaska)
Date: 2002-07-03 13:25

Message:
Logged In: YES 
user_id=279065

What's he saying?  val is defined as TEXT, as far as I can 
tell.  Why would one use LIKE with val, but not with the 
other string variables, changed, sid and name?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=474478&group_id=31885

[Phplib-trackers] [ phplib-Bugs-511639 ] ORA-00997 (phplib 7.4 pr1)

[<no...@so...>]

Bugs item #511639, was opened at 2002-02-01 04:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=511639&group_id=31885

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rune Kallhovd (choozo)
Assigned to: Nobody/Anonymous (nobody)
Summary: ORA-00997 (phplib 7.4 pr1)

Initial Comment:
PHP 4.0.4.pl1, Oracle 8.1.7

When setting up the basics and accessing the
../pages/index.php3 file, I get the following error:

"Warning: OCIStmtExecute: ORA-00997: illegal use of
LONG datatype in /usr/local/apache/php/db_oci8.inc on
line 69"

"ORA-00997: illegal use of LONG datatype 
Query :"select count(*) from active_sessions where
val='RXhhbXBsZV9TZXNzaW9uOiR0aGlzLT5pbiA9ICcwJzsgJHRoaXMtPnB0ID0gYXJyYXkoKTsgJHRoaXMtPnB0WydzJ10gPSAnMSc7ICRHTE9CQUxTWydzJ10gPSAnMSc7IA=='
and changed='20020201104234' and
sid='e4b3d2080c584cb390de104b299ff54a' and
name='Example_Session'"

 -----------------------------------------

Editing the function 'ac_store()' ($squery) in
ct_sql.inc as follows 'fixes' this, but this is
probably not what one want to do?:

(removed "val='%s'" from the 'sprintf()', and commented
'$str'.)

$squery = sprintf("select count(*) from %s where
changed='%s' and sid='%s' and name='%s'",
      $this->database_table,
      # $str,
      $now,
      $id,
      $name); 

 ------------------------------------------

Cheers :-)

----------------------------------------------------------------------

>Comment By: Jesse Swensen (swensenj)
Date: 2002-07-03 19:27

Message:
Logged In: YES 
user_id=168883

The long data type is used because the next larges size in Oracle is 
4000 characters.  This could easily be overflowed by a session.  

The val is not really needed for this query.  The purpose for this query is 
to determine if there is a session for this user.  So, the key information 
is the session name, sid and when it was changed.  This is the only 
information needed as it produces a unique row. (Actually session name 
and sid are the primary key and produce a unique row.)

There is an alternitve to using a long, but you have to use the split 
session.  This is where the session class store the data in a specific 
block size (2000 characters).  If the session info exceeds the block 
size, it creates another row and keeps track of how to put it back 
together.  This is what I use in my Oracle installations, because longs 
have some other "problems" as well. 

----------------------------------------------------------------------

Comment By: nathan hruby (nhruby)
Date: 2002-07-03 17:46

Message:
Logged In: YES 
user_id=19736

Why would VAL be a LONG?  It appears from the output it's a
string/TEXT.  This would cause an issue as it would be
*possible* that the query would return more than one row,
where I think we only want one..

Essentailly we're saying find me the number of rows that
have this data, where changed at this time and have this
session id.  Since it's possible to fake a sid and every so
slightly possibel to get the 'changed' sttribute to match,
this might present a bug in the long run as the serialized
session data *should* be unique due to an MD5 being run
somehwere int here (if memory serves me correctly.. please
double check)

The better solution would be to make the query and table
defs work as expected as opposed to floating a new change
acess all the db classes...

----------------------------------------------------------------------

Comment By: Jesse Swensen (swensenj)
Date: 2002-07-03 17:18

Message:
Logged In: YES 
user_id=168883

You can not use a LONG data type in the where clause.  The fix 
presented would fix the problem, but we should make sure the fix works 
across the other databases.

----------------------------------------------------------------------

Comment By: Chris Johnson (chaska)
Date: 2002-07-03 16:47

Message:
Logged In: YES 
user_id=279065

Could it be that the active sessions table is not defined 
correctly?  That column should be "text" or the Oracle 
equivalent (sorry I don't remember -- haven't done Oracle 
in 3 years).

..chris

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=511639&group_id=31885

[Phplib-trackers] [ phplib-Bugs-561019 ] db_pgsql.inc: lock() causes a warning

[<no...@so...>]

Bugs item #561019, was opened at 2002-05-27 05:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885

Category: DB_SQL
Group: current CVS
Status: Open
Resolution: None
Priority: 5
Submitted By: Marco Pratesi (pratesi)
Assigned to: Nobody/Anonymous (nobody)
Summary: db_pgsql.inc: lock() causes a warning

Initial Comment:
With the PostgreSQL class, the following code causes a
warning:

$qid = new DB_Sql();
$qid->lock("tablename");

The warning is:

Warning: Supplied argument is not a valid PostgreSQL
link resource...

This is due to the fact that in this case the
constructor issues
an empty query, that causes a "return 0" without issuing
"$this-connect()".
When lock() is requested, the following line is executed:

$result = pg_Exec($this->Link_ID, "lock table $table");

but $this->Link_ID is not a valid link, as connect()
has not been
executed yet.
The problem could be solved using $this->query() instead of
pg_Exec(), in analogy to what is done in db_mysql.inc,
as in the following:

$result = $this->query("lock table $table");


----------------------------------------------------------------------

>Comment By: Chris Johnson (chaska)
Date: 2002-07-03 17:15

Message:
Logged In: YES 
user_id=279065

I say go for it.  

I think getting a packaged pre-release out the door is 
more important at this point in time than trying to scare 
up the people and resources to do that kind of coverage 
testing.

..chris

----------------------------------------------------------------------

Comment By: nathan hruby (nhruby)
Date: 2002-07-03 16:56

Message:
Logged In: YES 
user_id=19736

> Maybe we should just bite the bullet and commit this stuff
> to -stable and then fix any problems which arise.

Yes please :)  

That's what the -pre's are for.. to suss out the bugs by the
advertursome and intelligent users before releasing to the
masses.

----------------------------------------------------------------------

Comment By: Richard Archer (richardarcher)
Date: 2002-07-03 16:46

Message:
Logged In: YES 
user_id=279311

I did a lot of work on some of the db classes (MySQL, OCI8,
ODBC come to mind). But I don't have most of those other
databases running to test with. I think you'll find most of
my work is in the devel tree only. I wasn't willing to
commit untested code to the -stable tree.

For example, the odbc driver in devel has *heaps* of
improvements and bug fixes. It even implements lock(). While
I did have an ODBC datasource at the time, I wasn't willing
to commit a 500 line patch to -stable based on my
development testing alone. 

Maybe we should just bite the bullet and commit this stuff
to -stable and then fix any problems which arise.


----------------------------------------------------------------------

Comment By: Chris Johnson (chaska)
Date: 2002-07-03 16:05

Message:
Logged In: YES 
user_id=279065

I thought one of our fearless programmers had gone 
through the db_* classes and made them more uniform?  
Or was a I dreaming?

..chris

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885

[Phplib-trackers] [ phplib-Bugs-561019 ] db_pgsql.inc: lock() causes a warning

[<no...@so...>]

Bugs item #561019, was opened at 2002-05-27 06:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885

Category: DB_SQL
Group: current CVS
Status: Open
Resolution: None
Priority: 5
Submitted By: Marco Pratesi (pratesi)
Assigned to: Nobody/Anonymous (nobody)
Summary: db_pgsql.inc: lock() causes a warning

Initial Comment:
With the PostgreSQL class, the following code causes a
warning:

$qid = new DB_Sql();
$qid->lock("tablename");

The warning is:

Warning: Supplied argument is not a valid PostgreSQL
link resource...

This is due to the fact that in this case the
constructor issues
an empty query, that causes a "return 0" without issuing
"$this-connect()".
When lock() is requested, the following line is executed:

$result = pg_Exec($this->Link_ID, "lock table $table");

but $this->Link_ID is not a valid link, as connect()
has not been
executed yet.
The problem could be solved using $this->query() instead of
pg_Exec(), in analogy to what is done in db_mysql.inc,
as in the following:

$result = $this->query("lock table $table");


----------------------------------------------------------------------

>Comment By: nathan hruby (nhruby)
Date: 2002-07-03 17:56

Message:
Logged In: YES 
user_id=19736

> Maybe we should just bite the bullet and commit this stuff
> to -stable and then fix any problems which arise.

Yes please :)  

That's what the -pre's are for.. to suss out the bugs by the
advertursome and intelligent users before releasing to the
masses.

----------------------------------------------------------------------

Comment By: Richard Archer (richardarcher)
Date: 2002-07-03 17:46

Message:
Logged In: YES 
user_id=279311

I did a lot of work on some of the db classes (MySQL, OCI8,
ODBC come to mind). But I don't have most of those other
databases running to test with. I think you'll find most of
my work is in the devel tree only. I wasn't willing to
commit untested code to the -stable tree.

For example, the odbc driver in devel has *heaps* of
improvements and bug fixes. It even implements lock(). While
I did have an ODBC datasource at the time, I wasn't willing
to commit a 500 line patch to -stable based on my
development testing alone. 

Maybe we should just bite the bullet and commit this stuff
to -stable and then fix any problems which arise.


----------------------------------------------------------------------

Comment By: Chris Johnson (chaska)
Date: 2002-07-03 17:05

Message:
Logged In: YES 
user_id=279065

I thought one of our fearless programmers had gone 
through the db_* classes and made them more uniform?  
Or was a I dreaming?

..chris

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885

[Phplib-trackers] [ phplib-Bugs-511639 ] ORA-00997 (phplib 7.4 pr1)

[<no...@so...>]

Bugs item #511639, was opened at 2002-02-01 04:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=511639&group_id=31885

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rune Kallhovd (choozo)
Assigned to: Nobody/Anonymous (nobody)
Summary: ORA-00997 (phplib 7.4 pr1)

Initial Comment:
PHP 4.0.4.pl1, Oracle 8.1.7

When setting up the basics and accessing the
../pages/index.php3 file, I get the following error:

"Warning: OCIStmtExecute: ORA-00997: illegal use of
LONG datatype in /usr/local/apache/php/db_oci8.inc on
line 69"

"ORA-00997: illegal use of LONG datatype 
Query :"select count(*) from active_sessions where
val='RXhhbXBsZV9TZXNzaW9uOiR0aGlzLT5pbiA9ICcwJzsgJHRoaXMtPnB0ID0gYXJyYXkoKTsgJHRoaXMtPnB0WydzJ10gPSAnMSc7ICRHTE9CQUxTWydzJ10gPSAnMSc7IA=='
and changed='20020201104234' and
sid='e4b3d2080c584cb390de104b299ff54a' and
name='Example_Session'"

 -----------------------------------------

Editing the function 'ac_store()' ($squery) in
ct_sql.inc as follows 'fixes' this, but this is
probably not what one want to do?:

(removed "val='%s'" from the 'sprintf()', and commented
'$str'.)

$squery = sprintf("select count(*) from %s where
changed='%s' and sid='%s' and name='%s'",
      $this->database_table,
      # $str,
      $now,
      $id,
      $name); 

 ------------------------------------------

Cheers :-)

----------------------------------------------------------------------

>Comment By: nathan hruby (nhruby)
Date: 2002-07-03 17:46

Message:
Logged In: YES 
user_id=19736

Why would VAL be a LONG?  It appears from the output it's a
string/TEXT.  This would cause an issue as it would be
*possible* that the query would return more than one row,
where I think we only want one..

Essentailly we're saying find me the number of rows that
have this data, where changed at this time and have this
session id.  Since it's possible to fake a sid and every so
slightly possibel to get the 'changed' sttribute to match,
this might present a bug in the long run as the serialized
session data *should* be unique due to an MD5 being run
somehwere int here (if memory serves me correctly.. please
double check)

The better solution would be to make the query and table
defs work as expected as opposed to floating a new change
acess all the db classes...

----------------------------------------------------------------------

Comment By: Jesse Swensen (swensenj)
Date: 2002-07-03 17:18

Message:
Logged In: YES 
user_id=168883

You can not use a LONG data type in the where clause.  The fix 
presented would fix the problem, but we should make sure the fix works 
across the other databases.

----------------------------------------------------------------------

Comment By: Chris Johnson (chaska)
Date: 2002-07-03 16:47

Message:
Logged In: YES 
user_id=279065

Could it be that the active sessions table is not defined 
correctly?  That column should be "text" or the Oracle 
equivalent (sorry I don't remember -- haven't done Oracle 
in 3 years).

..chris

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=511639&group_id=31885

[Phplib-trackers] [ phplib-Bugs-561019 ] db_pgsql.inc: lock() causes a warning

[<no...@so...>]

Bugs item #561019, was opened at 2002-05-27 20:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885

Category: DB_SQL
Group: current CVS
Status: Open
Resolution: None
Priority: 5
Submitted By: Marco Pratesi (pratesi)
Assigned to: Nobody/Anonymous (nobody)
Summary: db_pgsql.inc: lock() causes a warning

Initial Comment:
With the PostgreSQL class, the following code causes a
warning:

$qid = new DB_Sql();
$qid->lock("tablename");

The warning is:

Warning: Supplied argument is not a valid PostgreSQL
link resource...

This is due to the fact that in this case the
constructor issues
an empty query, that causes a "return 0" without issuing
"$this-connect()".
When lock() is requested, the following line is executed:

$result = pg_Exec($this->Link_ID, "lock table $table");

but $this->Link_ID is not a valid link, as connect()
has not been
executed yet.
The problem could be solved using $this->query() instead of
pg_Exec(), in analogy to what is done in db_mysql.inc,
as in the following:

$result = $this->query("lock table $table");


----------------------------------------------------------------------

>Comment By: Richard Archer (richardarcher)
Date: 2002-07-04 07:46

Message:
Logged In: YES 
user_id=279311

I did a lot of work on some of the db classes (MySQL, OCI8,
ODBC come to mind). But I don't have most of those other
databases running to test with. I think you'll find most of
my work is in the devel tree only. I wasn't willing to
commit untested code to the -stable tree.

For example, the odbc driver in devel has *heaps* of
improvements and bug fixes. It even implements lock(). While
I did have an ODBC datasource at the time, I wasn't willing
to commit a 500 line patch to -stable based on my
development testing alone. 

Maybe we should just bite the bullet and commit this stuff
to -stable and then fix any problems which arise.


----------------------------------------------------------------------

Comment By: Chris Johnson (chaska)
Date: 2002-07-04 07:05

Message:
Logged In: YES 
user_id=279065

I thought one of our fearless programmers had gone 
through the db_* classes and made them more uniform?  
Or was a I dreaming?

..chris

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885

[Phplib-trackers] [ phplib-Bugs-540956 ] default login problem solved (login_if)

[<no...@so...>]

Bugs item #540956, was opened at 2002-04-08 08:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=540956&group_id=31885

Category: docs
Group: current CVS
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Dr Tarique Sani (tarique)
Summary: default login problem solved (login_if)

Initial Comment:
Hi, i solved a login_if problem. I wonder if someone else experienced this issue!?.

PHPlib 7.2 under Linux 2.4.10 (SuSE 7.3) with Konqueror.

By using the default login feature (var $nobody = true;)i discovered a problem while login in as a specific user (via url?again=yes): 
The login form claimed 'Either your username ... are invalid' even if i definitly put in the correct username/password.

I found a vulnerability (bug?) in the *loginform.ihtml files: They use 

<form name="login" action="<?php print $this->url() ?>" method=post> 

to redirect to the page you come from. 
Unfortunately this gives the 'again=yes' back and results in a 'login-loop'.

Hint: Replace the PHP line above with:

<form name="login" action="<?php 
    $full_url = $this->url();
    $url = substr($full_url,0,strpos($full_url,"?"));
    print $url; ?>" method=post>

This should fix the problem.
Sascha

----------------------------------------------------------------------

>Comment By: nathan hruby (nhruby)
Date: 2002-07-03 17:28

Message:
Logged In: YES 
user_id=19736

Becasue the ?again=yes syntax is specfic to the example pages.  

There's no magic flag in the auth code the looks for again
and forces a login if it's there, that is left up to the end
user.  IMHO, this is better becasie it can be more flexible
(a developer can use any flag they so desire); however, it
also means that the user/devloper needs to remove her
specific relogin flag at reauth time to avoid the loop.

It's a doc bug because I don't think it's clear that the
again=yes symantics are examples, and not hardcoded class
restrictions.  Also, the documentation should be updated to
remind the devloper to remove her flag before begining the
login process.

In the end it may be better to implement this is a class
option; however I don't feel that is a prudent thing to do
in 7.x.

----------------------------------------------------------------------

Comment By: Chris Johnson (chaska)
Date: 2002-07-03 16:54

Message:
Logged In: YES 
user_id=279065

Why is this a doc bug instead of fixing code as suggested 
in defauth.php3?

Color me confused,
..chris

----------------------------------------------------------------------

Comment By: nathan hruby (nhruby)
Date: 2002-07-02 16:09

Message:
Logged In: YES 
user_id=19736

Wouldn't this crush any GET requests during the login
process?  The 'again' needs to be stripped but not all of
the GET request.

See comment in top of pages/defauth.php3 for a better way to
remove the 'again'.

Well. that's a pain.. here's the copy.. :)
  // Remove the "again=yes" from QUERY_STRING. This is required
  // because the login form will be submitted to the URL of this
  // page. This URL is constructed from $PHP_SELF and
$QUERY_STRING.
  // So, we need to remove this parameter from QUERY_STRING
or else
  // after the user submits a username and password, we will
unauth 
  // them before they even get logged in!
  $HTTP_SERVER_VARS["QUERY_STRING"] = ereg_replace(
    "(^|&)again=yes(&|$)",
    "\1", $HTTP_SERVER_VARS["QUERY_STRING"]);

Marking this as a documentation bug, as it something that
needs to be added to the docs
 :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=540956&group_id=31885

[Phplib-trackers] [ phplib-Bugs-511639 ] ORA-00997 (phplib 7.4 pr1)

[<no...@so...>]

Bugs item #511639, was opened at 2002-02-01 04:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=511639&group_id=31885

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rune Kallhovd (choozo)
Assigned to: Nobody/Anonymous (nobody)
Summary: ORA-00997 (phplib 7.4 pr1)

Initial Comment:
PHP 4.0.4.pl1, Oracle 8.1.7

When setting up the basics and accessing the
../pages/index.php3 file, I get the following error:

"Warning: OCIStmtExecute: ORA-00997: illegal use of
LONG datatype in /usr/local/apache/php/db_oci8.inc on
line 69"

"ORA-00997: illegal use of LONG datatype 
Query :"select count(*) from active_sessions where
val='RXhhbXBsZV9TZXNzaW9uOiR0aGlzLT5pbiA9ICcwJzsgJHRoaXMtPnB0ID0gYXJyYXkoKTsgJHRoaXMtPnB0WydzJ10gPSAnMSc7ICRHTE9CQUxTWydzJ10gPSAnMSc7IA=='
and changed='20020201104234' and
sid='e4b3d2080c584cb390de104b299ff54a' and
name='Example_Session'"

 -----------------------------------------

Editing the function 'ac_store()' ($squery) in
ct_sql.inc as follows 'fixes' this, but this is
probably not what one want to do?:

(removed "val='%s'" from the 'sprintf()', and commented
'$str'.)

$squery = sprintf("select count(*) from %s where
changed='%s' and sid='%s' and name='%s'",
      $this->database_table,
      # $str,
      $now,
      $id,
      $name); 

 ------------------------------------------

Cheers :-)

----------------------------------------------------------------------

>Comment By: Jesse Swensen (swensenj)
Date: 2002-07-03 17:18

Message:
Logged In: YES 
user_id=168883

You can not use a LONG data type in the where clause.  The fix 
presented would fix the problem, but we should make sure the fix works 
across the other databases.

----------------------------------------------------------------------

Comment By: Chris Johnson (chaska)
Date: 2002-07-03 16:47

Message:
Logged In: YES 
user_id=279065

Could it be that the active sessions table is not defined 
correctly?  That column should be "text" or the Oracle 
equivalent (sorry I don't remember -- haven't done Oracle 
in 3 years).

..chris

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=511639&group_id=31885

[Phplib-trackers] [ phplib-Bugs-561019 ] db_pgsql.inc: lock() causes a warning

[<no...@so...>]

Bugs item #561019, was opened at 2002-05-27 05:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885

Category: DB_SQL
Group: current CVS
Status: Open
Resolution: None
Priority: 5
Submitted By: Marco Pratesi (pratesi)
Assigned to: Nobody/Anonymous (nobody)
Summary: db_pgsql.inc: lock() causes a warning

Initial Comment:
With the PostgreSQL class, the following code causes a
warning:

$qid = new DB_Sql();
$qid->lock("tablename");

The warning is:

Warning: Supplied argument is not a valid PostgreSQL
link resource...

This is due to the fact that in this case the
constructor issues
an empty query, that causes a "return 0" without issuing
"$this-connect()".
When lock() is requested, the following line is executed:

$result = pg_Exec($this->Link_ID, "lock table $table");

but $this->Link_ID is not a valid link, as connect()
has not been
executed yet.
The problem could be solved using $this->query() instead of
pg_Exec(), in analogy to what is done in db_mysql.inc,
as in the following:

$result = $this->query("lock table $table");


----------------------------------------------------------------------

>Comment By: Chris Johnson (chaska)
Date: 2002-07-03 16:05

Message:
Logged In: YES 
user_id=279065

I thought one of our fearless programmers had gone 
through the db_* classes and made them more uniform?  
Or was a I dreaming?

..chris

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885

[Phplib-trackers] [ phplib-Bugs-550783 ] Malformed $QUERY_STRING with PHP 4.2.0

[<no...@so...>]

Bugs item #550783, was opened at 2002-04-30 16:10
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=550783&group_id=31885

Category: Session
Group: 7.4pre1
Status: Open
Resolution: None
>Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Malformed $QUERY_STRING with PHP 4.2.0

Initial Comment:
I'm using PHPLib 7.4pre1 with PHP 4.2.0(maybe latest
version at now).

$sess->purl() method in login.ihtml outputs the extra
string `?\1' when session id is only included in
$QUERY_STRING.

For example, the following code is written.

  .../login.php?\1

This problem is caused by ereg_replace function in PHP
4.2.0. In 4.1.2, \digit(back-references) is replaced
to "" when referenced string is "", but in 4.2.0
replaced to `\digit'.

The following is the part of get_id() method in Session
class.

// Remove session ID info from QUERY String - it is in
cookie
if ( isset($QUERY_STRING) && ("" != $QUERY_STRING) ) {
  $QUERY_STRING = ereg_replace(
"(^|&)".quotemeta(urlencode($this->name))."=".$id."(&|$)",
"\1", $QUERY_STRING);
}
Finally, I added the the following code fragment:

  $QUERY_STRING = ereg_replace("\\1", "",        
$QUERY_STRING);

Of cource, this is not a bug. I think that this is a
effet of multi-byte extension to regexp feature in PHP.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=550783&group_id=31885

[Phplib-trackers] [ phplib-Bugs-550100 ] ct_sql/ac_get_lock() MySQL-only

[<no...@so...>]

Bugs item #550100, was opened at 2002-04-29 05:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=550100&group_id=31885

Category: None
Group: 7.4pre1
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Archer (richardarcher)
Assigned to: Nobody/Anonymous (nobody)
Summary: ct_sql/ac_get_lock() MySQL-only

Initial Comment:
What is this MySQL-dependent code doing in the ct_sql
class? At a minimum this should be abstracted via the
db_*_sql classes. But since MySQL is (AFAIK) the only
database to implement application-level locks, this is
difficult.

Really, this should be implemented in a manner
independent of both databases and storage containers. 

Having a separate table with a key of the session id or
application name and inserting/deleting rows in thaw()
and freeze() would seem appropriate. That would be
quite flexible, offering a way of single-threading both
the entire application and a single session. 

My pseudo-locking code in the -devel db_odbc.inc may be
a good base for this.

I don't think changing the API for this function would
matter. It has never actually worked, so we can't break
existing installations.


----------------------------------------------------------------------

>Comment By: Chris Johnson (chaska)
Date: 2002-07-03 16:02

Message:
Logged In: YES 
user_id=279065

Agreed.

----------------------------------------------------------------------

Comment By: nathan hruby (nhruby)
Date: 2002-07-01 16:56

Message:
Logged In: YES 
user_id=19736

Errr.... can we hold off a *llittle* while longer till 8.0?
 this would be a good reason to make everything extend from
base classes...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=550100&group_id=31885

[Phplib-trackers] [ phplib-Bugs-540956 ] default login problem solved (login_if)

[<no...@so...>]

Bugs item #540956, was opened at 2002-04-08 07:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=540956&group_id=31885

Category: docs
Group: current CVS
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Dr Tarique Sani (tarique)
Summary: default login problem solved (login_if)

Initial Comment:
Hi, i solved a login_if problem. I wonder if someone else experienced this issue!?.

PHPlib 7.2 under Linux 2.4.10 (SuSE 7.3) with Konqueror.

By using the default login feature (var $nobody = true;)i discovered a problem while login in as a specific user (via url?again=yes): 
The login form claimed 'Either your username ... are invalid' even if i definitly put in the correct username/password.

I found a vulnerability (bug?) in the *loginform.ihtml files: They use 

<form name="login" action="<?php print $this->url() ?>" method=post> 

to redirect to the page you come from. 
Unfortunately this gives the 'again=yes' back and results in a 'login-loop'.

Hint: Replace the PHP line above with:

<form name="login" action="<?php 
    $full_url = $this->url();
    $url = substr($full_url,0,strpos($full_url,"?"));
    print $url; ?>" method=post>

This should fix the problem.
Sascha

----------------------------------------------------------------------

>Comment By: Chris Johnson (chaska)
Date: 2002-07-03 15:54

Message:
Logged In: YES 
user_id=279065

Why is this a doc bug instead of fixing code as suggested 
in defauth.php3?

Color me confused,
..chris

----------------------------------------------------------------------

Comment By: nathan hruby (nhruby)
Date: 2002-07-02 15:09

Message:
Logged In: YES 
user_id=19736

Wouldn't this crush any GET requests during the login
process?  The 'again' needs to be stripped but not all of
the GET request.

See comment in top of pages/defauth.php3 for a better way to
remove the 'again'.

Well. that's a pain.. here's the copy.. :)
  // Remove the "again=yes" from QUERY_STRING. This is required
  // because the login form will be submitted to the URL of this
  // page. This URL is constructed from $PHP_SELF and
$QUERY_STRING.
  // So, we need to remove this parameter from QUERY_STRING
or else
  // after the user submits a username and password, we will
unauth 
  // them before they even get logged in!
  $HTTP_SERVER_VARS["QUERY_STRING"] = ereg_replace(
    "(^|&)again=yes(&|$)",
    "\1", $HTTP_SERVER_VARS["QUERY_STRING"]);

Marking this as a documentation bug, as it something that
needs to be added to the docs
 :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=540956&group_id=31885

[Phplib-trackers] [ phplib-Bugs-530291 ] JS forms validation with PHPLib

[<no...@so...>]

Bugs item #530291, was opened at 2002-03-15 06:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=530291&group_id=31885

>Category: OOH Forms
>Group: current CVS
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: JS forms validation with PHPLib

Initial Comment:
Can be bug in a class oohforms (PHPLid 7.2d, 7.4-pre):

When I add regex in the form's element definition  and 
element type is text and this element is the first in 
form, the method self_get_js() gives out erroneous JS-
code for the first element - it addresses to him 
elements[] instead of elements[0].

Here is some JS-code generated by phpLib validation:
--- cut ---
<script language='javascript'>
<!--
function paym_report_Validator(f) {
if (window.RegExp) {
  var reg = new RegExp("^[0-9]+$","g");
  if (!reg.test(f.elements[].value)) {
    alert("Numeric only");
    f.elements[].focus();
    return(false);
  }
}
if (window.RegExp) {
  var reg = new RegExp("^[0-9][0-9]\.[0-9][0-9]\.[0-9]
[0-9][0-9][0-9]$|^$","g");
  if (!reg.test(f.elements[1].value)) {
    alert("Date format : DD.MM.YYYY");
    f.elements[1].focus();
    return(false);
  }
}
}
//-->
</script>
--- cut ---


----------------------------------------------------------------------

Comment By: Erik Roest (tbird1993)
Date: 2002-03-16 02:24

Message:
Logged In: YES 
user_id=166685

I ran into the same problem, and made a workaround.
The real cause is not solved but it works anyway :).

A) Edit of_text.inc

B) goto line 64 where the following function starts:
64: function self_get_js($ndx_array) {
65:   $str = "";
66:
67:   reset($ndx_array);
68:   while (list($k,$n) = each($ndx_array)) {
69:

C) Add this:
70: if( !isset( $n ) ) $n=0; ## ER 20020311: BUGFIX

This fix should take care of it.

----------------------------------------------------------------------

Comment By: Erik Roest (tbird1993)
Date: 2002-03-16 02:23

Message:
Logged In: YES 
user_id=166685

I ran into the same problem, and made a workaround.
The real cause is not solved but it works anyway :).

A) Edit of_text.inc

B) goto line 64 where the following function starts:
64: function self_get_js($ndx_array) {
65:   $str = "";
66:
67:   reset($ndx_array);
68:   while (list($k,$n) = each($ndx_array)) {
69:

C) Add this:
70: if( !isset( $n ) ) $n=0; ## ER 20020311: BUGFIX

This fix should take care of it.

----------------------------------------------------------------------

Comment By: Denis S. Stepanov (ayanuz)
Date: 2002-03-15 07:02

Message:
Logged In: YES 
user_id=383633

When i was adding this bug, i couldn't add a file 
attachment. Here it is in plain text:
<-- cut valtest.php -->
<?php

  $t = new Template();
  $f = new form;

  $FORM = array(
        "F_FIELD1" => array(
                "type" => "text",
                "name" => "field1",
                "size" => "40",
                "value" => "",
                "valid_regex" => "^[0-9]*$",
                "valid_e" => "Numeric only"),
        "F_FIELD2" => array(
                "type" => "text",
                "name" => "field2",
                "size" => "10",
                "maxlength" => "10",
                "value" => "",
                "valid_regex" 
=> "^\d\d\.\d\d\.\d\d\d\d$|^$",
                "valid_e" => "Date format : DD.MM.YYYY"),
        "F_SUBMIT" => array(
                "type" => "submit",
                "name" => "check",
                "value" => "Check")
  );

  $t->set_file("page", "valtest.thtml");

  foreach ($FORM as $k => $v) {
        $f->add_element($v);
        $t->set_var($k, $f->get_element($v['name']));
  }

  $t->set_var(array(
        "F_START" => $f->get_start("valtest", "post", 
$PHP_SELF),
        "F_END" => $f->get_finish())
  );

  $t->pparse("OUT", "page");

?>
<-- cut valtest.php -->
<-- cut valtest.thtml -->
<html>
<head>
<title>Some PHPLib JS-validation testing</title>
</head>
<body>
Try to fill in form with invalid values and click "Check" 
button to validate data<p>

{F_START}
Some numeric : {F_FIELD1}<br>
Some date in DD.MM.YYYY style : {F_FIELD2}<p>
{F_SUBMIT}
{F_END}
</body>
</html>
<-- cut valtest.thtml -->


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=530291&group_id=31885

[Phplib-trackers] [ phplib-Bugs-512813 ] db_pgsql.inc : obsolete function name

[<no...@so...>]

Bugs item #512813, was opened at 2002-02-04 10:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=512813&group_id=31885

>Category: DB_SQL
>Group: current CVS
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: db_pgsql.inc : obsolete function name

Initial Comment:
db_pgsql.inc is using function names 
that will be obsolete in php version 4.2.0 


http://www.php.net/manual/en/ref.pgsql.php

PostgreSQL function names will be changed in 4.2.0 
release to confirm current coding standard. Most of 
new names will have additional under score(s), e.g. 
pg_lo_open(). Some functions are renamed to different 
name for consistency. e.g. pg_exec() to pg_query(). 
Older names may be used in 4.2.0 and a few releases 
from 4.2.0, but they may be deleted in the future. CVS 
version has new function names. 

Example 1. Function names changed

OLD NAME           NEW NAME
pg_exec            pg_query
getlastoid         pg_last_oid
pg_cmdtuples       pg_affected_rows
pg_errormessage    pg_last_error
pg_numrows         pg_num_rows
pg_numfields       pg_num_fields
pg_fieldname       pg_field_name
pg_fieldsize       pg_field_size
pg_fieldtype       pg_field_type
pg_fieldnum        pg_field_num
pg_fieldprtlen     pg_field_prtlen
pg_fieldisnull     pg_field_is_null
pg_freeresult      pg_free_result
pg_result          pg_fetch_result
pg_loreadall       pg_lo_read_all
pg_locreate        pg_lo_create
pg_lounlink        pg_lo_unlink
pg_loopen          pg_lo_open
pg_loclose         pg_lo_close
pg_loread          pg_lo_read
pg_lowrite         pg_lo_write
pg_loimport        pg_lo_import
pg_loexport        pg_lo_export
 
 
Obsolete pg_connect()/pg_pconnect() syntax will be 
depreciated to support async connect feature in the 
future. Please use connection string for pg_connect() 
and pg_pconnect(). 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=512813&group_id=31885

[Phplib-trackers] [ phplib-Bugs-511639 ] ORA-00997 (phplib 7.4 pr1)

[<no...@so...>]

Bugs item #511639, was opened at 2002-02-01 03:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=511639&group_id=31885

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rune Kallhovd (choozo)
Assigned to: Nobody/Anonymous (nobody)
Summary: ORA-00997 (phplib 7.4 pr1)

Initial Comment:
PHP 4.0.4.pl1, Oracle 8.1.7

When setting up the basics and accessing the
../pages/index.php3 file, I get the following error:

"Warning: OCIStmtExecute: ORA-00997: illegal use of
LONG datatype in /usr/local/apache/php/db_oci8.inc on
line 69"

"ORA-00997: illegal use of LONG datatype 
Query :"select count(*) from active_sessions where
val='RXhhbXBsZV9TZXNzaW9uOiR0aGlzLT5pbiA9ICcwJzsgJHRoaXMtPnB0ID0gYXJyYXkoKTsgJHRoaXMtPnB0WydzJ10gPSAnMSc7ICRHTE9CQUxTWydzJ10gPSAnMSc7IA=='
and changed='20020201104234' and
sid='e4b3d2080c584cb390de104b299ff54a' and
name='Example_Session'"

 -----------------------------------------

Editing the function 'ac_store()' ($squery) in
ct_sql.inc as follows 'fixes' this, but this is
probably not what one want to do?:

(removed "val='%s'" from the 'sprintf()', and commented
'$str'.)

$squery = sprintf("select count(*) from %s where
changed='%s' and sid='%s' and name='%s'",
      $this->database_table,
      # $str,
      $now,
      $id,
      $name); 

 ------------------------------------------

Cheers :-)

----------------------------------------------------------------------

>Comment By: Chris Johnson (chaska)
Date: 2002-07-03 15:47

Message:
Logged In: YES 
user_id=279065

Could it be that the active sessions table is not defined 
correctly?  That column should be "text" or the Oracle 
equivalent (sorry I don't remember -- haven't done Oracle 
in 3 years).

..chris

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=511639&group_id=31885

[Phplib-trackers] [ phplib-Bugs-504005 ] Session.put_headers wrong for PHP3

[<no...@so...>]

Bugs item #504005, was opened at 2002-01-15 12:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=504005&group_id=31885

Category: Session
Group: None
Status: Open
Resolution: None
>Priority: 2
Submitted By: Fred Yankowski (fredy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Session.put_headers wrong for PHP3

Initial Comment:
The put_headers() method in session.inc calls header() 
with 'false' as the second argument in some cases, to 
append to a header rather than replacing it.  This 
feature does not exist in PHP3, causing the header 
values to be incomplete because only the last value 
obtains.

The attached patch fixes this problem and should work 
in both PHP3 and PHP4.


----------------------------------------------------------------------

>Comment By: Chris Johnson (chaska)
Date: 2002-07-03 15:44

Message:
Logged In: YES 
user_id=279065

Yeah, current PHP documentation does not mention such 
a change, but I vaguely remember it being made several 
years ago.  Should we bother asking someone senior on 
the PHP development team, or should we just say PHPLIB 
only works with PHP 3.x.y + where x.y are beyond this 
change, most likely 3.0.5.

----------------------------------------------------------------------

Comment By: nathan hruby (nhruby)
Date: 2002-07-02 14:45

Message:
Logged In: YES 
user_id=19736

What version of php3 are you using?  I don't see mention of
when the second flag was added to the headers() function,
though I am fairly certian that it was part of php3...



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=504005&group_id=31885

[Phplib-trackers] [ phplib-Bugs-487852 ] fallback error

[<no...@so...>]

Bugs item #487852, was opened at 2001-12-01 10:36
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=487852&group_id=31885

>Category: Session
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Dieter Steinwedel (dsteinwe)
Assigned to: Nobody/Anonymous (nobody)
Summary: fallback error

Initial Comment:
I've recognized that the fallback mechanism from 
cookie to get doesn't work correctly. The created 
session always works, but sometimes the mechanism 
fallsback to "get" on session creation on browser with 
cookie support. 

The source of this behaviour may be "release_token()" 
and/or "get_id()" in "session.inc".

Dieter

----------------------------------------------------------------------

Comment By: Gaetano Giunta (ggiunta)
Date: 2002-01-10 09:01

Message:
Logged In: YES 
user_id=114789

DOH! I think the final suggestion in my previous post
is BULL$#!^: on the 
second load of the page you will NOT get back a session id from the browser, 
so you can't match it in the database!

Anyway, the brilliant idea to 
solve the problem is here:
1st hit: set cookie, reload adding GET 
params
2nd hit: if no cookie found continue using GETs, else
         reload, 
eliminating GET params
3rd hit: you're OK now, sure to get the 
cookie

the tradeoff is a slightly slower load-time of 1st-page-of-
session, your take...

the patch to session.inc I just posted here 
(see the patches section)


----------------------------------------------------------------------

Comment By: Gaetano Giunta (ggiunta)
Date: 2002-01-10 05:47

Message:
Logged In: YES 
user_id=114789

My 2 eurocents of analysis: it depends on session.inc, function 
release_token, line 406 (in release 7.4rc1): mode is set to 
fallback.

This looks unnecessary (and if your'sure all your users 
have cookies enabled just comment the line and all will be smooth), but it 
stems from a logic problem: if a page is hit by the browser and there's no 
cookie found containing the session id, there's no (easy) way that PHPLIB 
can possibly know if it is the first time that the page was hit and the 
session cookie has yet to be set, or if it is the second time that the page is 
hit and the cookie is not working, so session should switch to fallback 
mode. To make sure it gets it right, phplib adds the session id in the URL, 
although it looks a bit nasty to the end user.

An (hard and long ?) way to 
do it could be storing in the db container the session info on the first page 
hit, before redirecting the user. This way the second page hit would find 
the session id already defined in the db and know that if no cookie is there 
it should fall back to get mode and try a second redirect including the 
session id in the url...

Hope this helps a bit (and maybe even gets 
implemented in verion 8 or someting...)
Gaetano

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=487852&group_id=31885

[Phplib-trackers] [ phplib-Bugs-478978 ] function affected_rows() and ODBC

[<no...@so...>]

Bugs item #478978, was opened at 2001-11-06 21:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=478978&group_id=31885

Category: DB_SQL
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: function affected_rows() and ODBC

Initial Comment:
If you say "Many ODBC drivers don't support 
odbc_num_rows() on SELECT statements" -msaccess97 is 
one- why you use this function to set affected_rows()??
Will be better use your class function num_rows()?

----------------------------------------------------------------------

>Comment By: Chris Johnson (chaska)
Date: 2002-07-03 15:34

Message:
Logged In: YES 
user_id=279065

Sounds like he says phplib is using odbc_num_rows() to 
set affected_rows().  If so, that's not right.  Need to 
double-check the code.  In my somewhat older than 
current CVS version, this is in fact in error.  From 
db_odbc.inc:

function affected_rows() {
    return odbc_num_rows($this->Query_ID);
}

Unless, of course, PHP does something funky with 
odbc_num_rows() which results in correct behavior after 
an INSERT, UPDATE or DELETE.  Here's what 
www.php.net says on the subject:

odbc_num_rows() will return the number of rows in an 
ODBC result. This function will return -1 on error. For 
INSERT, UPDATE and DELETE statements odbc_num_rows
() returns the number of rows affected. For a SELECT 
clause this can be the number of rows available. 

Note: Using odbc_num_rows() to determine the number of 
rows available after a SELECT will return -1 with many 
drivers. 


So, I'd say this is NOT a bug.  Anyone have an ODBC 
driver to test it with?

..chris

----------------------------------------------------------------------

Comment By: nathan hruby (nhruby)
Date: 2002-07-02 14:14

Message:
Logged In: YES 
user_id=19736

Err.. I don't get it?

affected_rows() returns the number of rows changed by an
UPDATE, INSERT or DELETE statement

num_rows() returns the number of rows from a SELECT statement.  

The phplib num_rows is a thin wrapper around the php
function for the specific database you are using, it doesn't
create a num_rows in php.  A php version could be written;
however it would suffer horrible memory issues and would not
perform well on large queries.

The warning in the documentation I belive is there to make
the users aware that this specific fucntion isn't generally
well implemented by the udnerlying ODBC drivers, and
therefore isn't always availible.

Isn't there also a warning for async db's (like oracle) to
emulate this by getting the count of the intended query? 
Would this also work for the ODBC drivers as well?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=478978&group_id=31885

[Phplib-trackers] [ phplib-Bugs-474478 ] ac_store.inc and MS-SQL7

[<no...@so...>]

Bugs item #474478, was opened at 2001-10-24 09:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=474478&group_id=31885

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jaros³aw Zabie³³o (zbiru)
Assigned to: Nobody/Anonymous (nobody)
Summary: ac_store.inc and MS-SQL7

Initial Comment:
I changed "val='%s'" to "val like '%'" because MSSQL7 
cannot use variable='values' as a part of WHERE 
subquery. val should be also defined as TEXT, not 
VARCHAR(xxx). Open file ac.store.inc and change

old:

$squery = sprintf("select count(*) from %s where val 
= '%s' and changed='%s' and sid='%s' and name='%s'",

new:

$squery = sprintf("select count(*) from %s where val 
like '%s' and changed='%s' and sid='%s' and name='%s'",


----------------------------------------------------------------------

>Comment By: Chris Johnson (chaska)
Date: 2002-07-03 15:25

Message:
Logged In: YES 
user_id=279065

What's he saying?  val is defined as TEXT, as far as I can 
tell.  Why would one use LIKE with val, but not with the 
other string variables, changed, sid and name?

----------------------------------------------------------------------

Comment By: Chris Johnson (chaska)
Date: 2002-07-03 15:25

Message:
Logged In: YES 
user_id=279065

What's he saying?  val is defined as TEXT, as far as I can 
tell.  Why would one use LIKE with val, but not with the 
other string variables, changed, sid and name?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=474478&group_id=31885

[Phplib-trackers] [ phplib-Bugs-474478 ] ac_store.inc and MS-SQL7

[<no...@so...>]

Bugs item #474478, was opened at 2001-10-24 09:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=474478&group_id=31885

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jaros³aw Zabie³³o (zbiru)
Assigned to: Nobody/Anonymous (nobody)
Summary: ac_store.inc and MS-SQL7

Initial Comment:
I changed "val='%s'" to "val like '%'" because MSSQL7 
cannot use variable='values' as a part of WHERE 
subquery. val should be also defined as TEXT, not 
VARCHAR(xxx). Open file ac.store.inc and change

old:

$squery = sprintf("select count(*) from %s where val 
= '%s' and changed='%s' and sid='%s' and name='%s'",

new:

$squery = sprintf("select count(*) from %s where val 
like '%s' and changed='%s' and sid='%s' and name='%s'",


----------------------------------------------------------------------

>Comment By: Chris Johnson (chaska)
Date: 2002-07-03 15:25

Message:
Logged In: YES 
user_id=279065

What's he saying?  val is defined as TEXT, as far as I can 
tell.  Why would one use LIKE with val, but not with the 
other string variables, changed, sid and name?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=474478&group_id=31885

[Phplib-trackers] [ phplib-Bugs-471092 ] Update Quick Start (to use VHOST'ed install)

[<no...@so...>]

Bugs item #471092, was opened at 2001-10-15 04:45
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=471092&group_id=31885

Category: docs
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Dr Tarique Sani (tarique)
Summary: Update Quick Start (to use VHOST'ed install)

Initial Comment:
In section 1.3 of the documentation it says: VERY 
IMPORTANT NOTE: This is a quick installation guide to 
get you started if you have an installation where you 
control the web server, PHP interpreter and database 
server completely. They are not suitable for a web 
hosting setup where you have only limited to no 
control over the installation.

The fact is that if you're using apache, you can 
use .htaccess to change practically all settings of 
the php.ini file:

#not php.ini, but you can set php extensions
AddType application/x-httpd-php .phtml .php .inc .ihtml

#PHP Options (only examples)
php_value auto_prepend_file local.inc
php_value 
include_path .:/usr/local/lib/php:/home/user/www/phplib
php_flag asp_tags On

So as long as you have access to everything else, this 
isn't a problem.

----------------------------------------------------------------------

>Comment By: Dr Tarique Sani (tarique)
Date: 2002-07-03 12:57

Message:
Logged In: YES 
user_id=269695

OK! if someone would please send the rewritten thing in plain 
text then I promise to XMLise, regenerate, and update the site 
within 24 hours :)

----------------------------------------------------------------------

Comment By: Richard Archer (richardarcher)
Date: 2002-07-03 05:49

Message:
Logged In: YES 
user_id=279311

Here are my comments posted to the -core list about this issue:

I've never used the auto_prepend_file in the php3.ini way of
installing PHPLIB. I always use the $_PHPLIB["libdir"]  =
"/path/to/phplib/" method.

A couple of reasons for this:

- I don't want 60 kB of code auto-prepended to all scripts,
most of
  which aren't PHPLIB scripts and don't need the namespace
pollution.

- Different sites (virtual hosting environment) require
different
  configurations in prepend.php3 (i.e. sess only, sess+auth).

- Different sites may want to run different versions of PHPLIB,
  either choosing their own upgrade path or (god forbid) running
  hacked versions of PHPLIB.

- On my first installation (PHPLIB-6.1, early 1999) I found the
  documentation horribly confusing and set it up the easiest
way.


Even now I know all about the package and how to configure
it with auto_prepend_file, I still prefer the $_PHPLIB option.

The $_PHPLIB method always works, while the auto_... method
is only applicable under certain circumstances which are
valid on the NetUSE chroot'd server farm and on corporate
servers where there is only one site running on the server.

I'd like to re-write the installation section of the manual
to make the $_PHPLIB["libdir"] the preferred installation
method and to refer to the auto_prepend_file way as an
alternative. Or maybe drop it all together.



----------------------------------------------------------------------

Comment By: nathan hruby (nhruby)
Date: 2002-07-03 03:53

Message:
Logged In: YES 
user_id=19736

Then I think the bug is: Quick Start Shoud detail a VHost'ed
install.

I agree with this sentiment.  Tarique & Layne, would confer
to rewrite the Quick Start to reflect these changes please?

Changing Bug Summary to reflect finalized bug

----------------------------------------------------------------------

Comment By: Dr Tarique Sani (tarique)
Date: 2002-07-02 19:50

Message:
Logged In: YES 
user_id=269695

What is the bug?

The document clearly states that see the next chapter for more 
information! 

Should QuickStart section be changed to show the usage of .htaccess 
only - this sounds logical as most people use it in vhost env 



----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2002-07-02 07:26

Message:
Logged In: YES 
user_id=278685

FWIW, I'd like to see the prefered installation in the 
documentation be a virtual hosting environment. Each 
site/project has its own copy of prepend.inc and local.inc in a 
non-servable user-specified location (personally I 
use /var/www/projectname/includes where web accessible 
files are in /var/www/projectname/docs).

----------------------------------------------------------------------

Comment By: nathan hruby (nhruby)
Date: 2002-07-02 06:52

Message:
Logged In: YES 
user_id=19736

phplib is easier to install if you have root.

I'm not seeing the bug, do you want the docs changed to
reflect .htaccess instructions or would like the design
changed to make something about installation easier?

Making this a docs bug...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=471092&group_id=31885

[Phplib-trackers] [ phplib-Patches-548449 ] CC validation formula

[<no...@so...>]

Patches item #548449, was opened at 2002-04-25 16:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403613&aid=548449&group_id=31885

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Archer (richardarcher)
Assigned to: Nobody/Anonymous (nobody)
Summary: CC validation formula

Initial Comment:
From: Lindsay Haisley

Here's a neat little piece which I put together to
check credit card
numbers.  The algorithm for doing this is based on
what's called the LUHN
formula which you can find lots of places such as
<http://www.webopedia.com/TERM/L/Luhn_formula.html>
although credit card
companies won't tell you what it is :-).  This might
make a nice add-on to
the cart class, although it's certainly functionally
peripheral to operation
of the class.



----------------------------------------------------------------------

>Comment By: Richard Archer (richardarcher)
Date: 2002-07-03 07:31

Message:
Logged In: YES 
user_id=279311

I don't know what's going on here... I reckon there's at
least 4 notes I've posted to these trackers that have gone
missing.

Anyway, here's the LUHN script.

----------------------------------------------------------------------

Comment By: nathan hruby (nhruby)
Date: 2002-07-03 07:26

Message:
Logged In: YES 
user_id=19736

Umm.. There's no patch attached to this tracker Item :)

Anyone got one?  If not I'm closing the patch...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403613&aid=548449&group_id=31885

[Phplib-trackers] [ phplib-Patches-450706 ] Enhancements to OCI8 support

[<no...@so...>]

Patches item #450706, was opened at 2001-08-14 01:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403613&aid=450706&group_id=31885

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Archer (richardarcher)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhancements to OCI8 support

Initial Comment:
Here is a compilation of enhancements and bug fixes to
php-lib-devel/php/db/oci8/db_sql.inc

I don't have an Oracle database (yet!) so I'm not
willing to commit the changes (even to the -devel tree)
without testing. Could someone with Oracle running
please make sure these work as expected?

Some of these changes are bug fixes that should
probably be committed to -stable as well.

These changes are sourced from:
The -stable tree
A patch posted to the list by Ignatius TeoA patch
posted to the list by Jesse Swensen
Jesse says:
Here are my changes to oci8.inc.  There are four 
things changed you need to be aware of:
1) new instance variable, $autoCommit.  
Default is 1, commit.  You can either set it when 
you subclass db_sql for the default value or you can 
set it interactively for each db_sql instance, i.e.
$db = new DB_Example;
$db->autoCommit = 0;
2) new methods commit and rollback.
3) every time query is called it will recycle the 
old cursor(call to freeStatement).  As a result, you 
can call query as many times as you like without 
fear of the "too many open cursors" error.
4) new method freeStatement.



----------------------------------------------------------------------

>Comment By: nathan hruby (nhruby)
Date: 2002-07-02 17:27

Message:
Logged In: YES 
user_id=19736

Anything ever happen with this?  Has it been added, tested..?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403613&aid=450706&group_id=31885