[phplib] Things that make phplib NOT work out of the box with IIS and MSSQL From: Christof Beaupoil (beaupoil <email protected>)
Date: 11/08/00

Well, most of these bugs were reported already to the list but it took
me three
nights to find them all and I think some people might find this resume
helpfull:

Things that make phplib NOT work out of the box with IIS and MSSQL:

1. Sessionmanagement brakes
Reason: IIS does not send a cookie and a redirect in the same header.
Fix: Use META REFRESH instead (you have to change the function
release_token() in session.inc:
replace
l392 // header("Status: 302 Moved Temporarily");
l401 // header("Location: ". $PROTOCOL.
"://".$HTTP_HOST.$this->self_url());
by:
echo "<meta http-equiv=\"Refresh\"
content=\"0;URL=".$this->self_url()."\">\n";

2. Sessionmanagement + db_mssql.inc
wonīt work īcause phplib needs a funtion affected_rows() which MSSQL
doesnīt support
there are three possible patches. (make affected_rows() return 1 all the
time, recalculate the result doing a select query and the third one I
donīt remeber because we switched to ODBC like anybody else I asked...)
It seems that NOBODY is actually using db_mssql.inc.
Please tell me if Iīm wrong (and send me a copy of your db_mssql.inc ;)

3. like us you probably gonna end up using db_odbc.inc but for some
reason in all downloadable versions of phplib some functions are
missing!
3.1 nextid() which must have been in there in former times īcause we
found a patched version of it. It doesnīt help īcause it needs
3.2 lock() and unlock() to work properly which are simply noneexistent.

DOES ANYBODY KNOW WHAT HAPPEND TO THESE FUNCTIONS?

4. class table wonīt work with ODBC for two reasons:
4.1 if you use column names with capital letters next_record() is gonna
cast them to lower case just like p() and f() do. Fine but table_show()
calls next_record() so it gets the lower case colnames but it does not
call p() or f() to print out a cell but looks for the uppercase
colnames.....
FIX: use only lowercase colnames :)

4.2 (this one was more difficult to find) the "ugly patch" (like it says
in the code :) of missing num_rows() funtions in some odbcīs works. BUT
JUST ONE TIME! table->show_result() calls the function TWO TIMES (plus
us checking for result) which makes table_show() showing exactly
nothing.
FIX: make db_odbc remember the value for num_rows() and not checking it
twice. There is a quite long posting from Michael Anthon in the archive:

List: phplib
Subject: [PHPLIB] db_odbc.inc, table.inc and num_rows vagaries
From: Michael Anthon <mca <email protected>>
Date: 2000-03-04 1:35:52

who btw seems to be the only guy on planet looking for patches for
db_odbc or db_mssql(THANX Michael!). Michaels posting on that error is
great he just missed telling that you have to set $RecordCount =
$num_rows before returning $num_rows at the end of num_rows(). Doing
this table_show() works fine for us. Michael reported an other problem
in his posting which didnīt occure in our case.

I gonna end quoting a posting from the archive:

"...Furthermore, the database abstraction layer from PHPLIB
doesn't seem to be very consistent and portable. We
had to fiddle around a lot with db_oci8.inc until it
worked nearly as we expected to work."

Which is not a critic to the great guys who made phplib. We used it in
serveral LAMP based projects and it is GREAT!!! But knowing this, it
hits you hard when you find out that the database abstraction layer
still doesnīt have the standard of the other phplib modules. I think
this is why so many people I talked to the last days just gave up and
started using LAMP again (one might think that this is exactly what
phplib creators want them to ;) Well I donīt like M$ and I think nobody
on this list does. But if the big advantage of PHP is that you can do
portable applications they should be portable to ALL systems. If you
REALLY have to port an application to IIS and MSSQL youīre not ending up
using LAMP but ASP. We do NOT want that.

We gonna keep on trying with phplib and report any error we find. Would
be great if the package maintainer could include some of the patches
above. So that the abstraction layer gets more useble and less people
give up.

cu
Christof Beaupoil

---------------------------------------------------------------------
To unsubscribe, e-mail: phplib-unsubscribe <email protected>
For additional commands, e-mail: phplib-help <email protected>