#67 ORA-00997 (phplib 7.4 pr1)

[Rune Kallhovd]

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

[Anonymous]

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

[Jesse Swensen]

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.

[nathan hruby]

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

[Jesse Swensen]

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.

[Jan Albrecht]

Logged In: YES
user_id=855408

Hi,

I got this problem also with the version 7.4.
Is there any solution in sight? Actually I'm trying to reduce
this field by using varchar2 or something similiar, but this is
just a dirty workaround.
Or do I have to replace all CT_SQL by CT_SPLIT_SQL?

Thanks

Jan