PHP’s Frustrating Flush
Posted May 19, 2008 
Comments(0)
Comments(0) PHP Extension order and Core Dumps
Posted December 5, 2007 Comments(2)
Comments(2) After updating my FreeBSD port php and apache I suddenly got a whole lot of core dumps. The hosted websites were running fine, but the core dumps didn’t feel quite right.. (of course).
Another FreeBSD server of mine, also updated to the same version, didn’t have these core dumps.
Doing some research on the web I found that a wrong order in extensions.ini could be a cause of my problems.
Changing the order of the extensions.ini solved my problem!
The following extensions.ini is is working for me:
extension=fileinfo.so
extension=filter.so
extension=json.so
extension=zip.so
extension=hash.so
extension=pdf.so
extension=pgsql.so
extension=ctype.so
extension=mysql.so
extension=mbstring.so
extension=gettext.so
extension=dba.so
extension=sysvshm.so
extension=gmp.so
extension=pdo.so
extension=tidy.so
extension=pcntl.so
extension=openssl.so
extension=readline.so
extension=simplexml.so
extension=calendar.so
extension=posix.so
extension=tokenizer.so
extension=bz2.so
extension=dbase.so
extension=xmlwriter.so
extension=ldap.so
extension=session.so
extension=sybase_ct.so
extension=exif.so
extension=sysvmsg.so
extension=mcrypt.so
extension=bcmath.so
extension=pdo_sqlite.so
extension=mssql.so
extension=sockets.so
extension=zlib.so
extension=pcre.so
extension=curl.so
extension=mhash.so
extension=imap.so
extension=iconv.so
extension=spl.so
extension=dom.so
extension=pspell.so
extension=soap.so
extension=xmlreader.so
extension=shmop.so
extension=sqlite.so
extension=xml.so
extension=xsl.so
extension=mysqli.so
extension=wddx.so
extension=sysvsem.so
extension=ftp.so
extension=xmlrpc.so
extension=snmp.so
extension=ncurses.so
extension=odbc.so
extension=ming.so
extension=gd.so
extension=filter.so
extension=json.so
extension=zip.so
extension=hash.so
extension=pdf.so
extension=pgsql.so
extension=ctype.so
extension=mysql.so
extension=mbstring.so
extension=gettext.so
extension=dba.so
extension=sysvshm.so
extension=gmp.so
extension=pdo.so
extension=tidy.so
extension=pcntl.so
extension=openssl.so
extension=readline.so
extension=simplexml.so
extension=calendar.so
extension=posix.so
extension=tokenizer.so
extension=bz2.so
extension=dbase.so
extension=xmlwriter.so
extension=ldap.so
extension=session.so
extension=sybase_ct.so
extension=exif.so
extension=sysvmsg.so
extension=mcrypt.so
extension=bcmath.so
extension=pdo_sqlite.so
extension=mssql.so
extension=sockets.so
extension=zlib.so
extension=pcre.so
extension=curl.so
extension=mhash.so
extension=imap.so
extension=iconv.so
extension=spl.so
extension=dom.so
extension=pspell.so
extension=soap.so
extension=xmlreader.so
extension=shmop.so
extension=sqlite.so
extension=xml.so
extension=xsl.so
extension=mysqli.so
extension=wddx.so
extension=sysvsem.so
extension=ftp.so
extension=xmlrpc.so
extension=snmp.so
extension=ncurses.so
extension=odbc.so
extension=ming.so
extension=gd.so
MSSQL Locking Problems
Posted September 14, 2007 Comments(0)
Comments(0) It has been a long time since my last post. Currently I’m very busy on a big project…
Yesterday we had a nice problem. A company I work is using the following configuration on it’s webserver: IIS, PHP and MSSQL. (yes an S). What’s wrong with this configuration? Well two things: IIS and MSSQL.
That’s not all: in PHP we connect to the database via 2 methods: via the ADODB COM object and the normal mssql functions from PHP.
We had the following problem in a certain module:
Every time we executed a Second query, the second query failed but we NEVER got an error message. Example:
(pseudo code:)
BEGIN TRANSACTION
SELECT * FROM mytable WHERE kind=’item1′
… more code …
SELECT * FROM mytable WHERE kind=’item2′ // <= This query failed every time, without an error message
... more code 2 ...
COMMIT TRANSACTION
SELECT * FROM mytable WHERE kind=’item1′
… more code …
SELECT * FROM mytable WHERE kind=’item2′ // <= This query failed every time, without an error message
... more code 2 ...
COMMIT TRANSACTION
Looks very strange, but after too many hours we found our problem:
(pseudo code:)
BEGIN TRANSACTION
… code 1 …
SELECT * FROM mytable WHERE kind=’item1′
…
INSERT .. INTO mytable( … ) VALUES ( … )
..
SELECT * FROM mytable WHERE kind=’item2′ // <= This query failed every time, without an error message
... code 3 ...
COMMIT TRANSACTION
… code 1 …
SELECT * FROM mytable WHERE kind=’item1′
…
INSERT .. INTO mytable( … ) VALUES ( … )
..
SELECT * FROM mytable WHERE kind=’item2′ // <= This query failed every time, without an error message
... code 3 ...
COMMIT TRANSACTION
What’s the problem:
BEGIN TRANSACTION # is executed by ADODB
SELECT * FROM … # is executed by mssql_* functions from PHP
INSERT … # is executed by ADODB
SELECT * FROM # is executed by mssql_* functions from PHP
..
SELECT * FROM … # is executed by mssql_* functions from PHP
INSERT … # is executed by ADODB
SELECT * FROM # is executed by mssql_* functions from PHP
..
Well when retrieving the data again the mssql_* connection fails because it notices the data has changed and it must wait for the other transaction to finish…
Aaaaaargh…. 8 hours of my time wasted!
Btw. A few year ago we had a good reason forusing ADODB in PHP: the mssql version of PHP wasn’t realiable. And we are using “queries from hell” ( sql server XML queries ), which (at that time) couldn’t be retrieve by the mssql functions of PHP.
Frustrating PHP 4 Objects
Posted August 13, 2007 Comments(0)
Comments(0) Today I tried the following:
function getObject()
{
$object = new Object();
return $object;
}
getObject()->executeMethod();
{
$object = new Object();
return $object;
}
getObject()->executeMethod();
Well the code above works perfectly …
All great, the app worked, so I’ve committed the project to Subversion.
Upload it to our production server..
Crash!
Well the production server runs PHP4.
Our development server runs PHP5.
In PHP4, You first must put the result of the method call in a variable…
$obj = getObject();
$obj->executeMethod();
$obj->executeMethod();
*sigh* Sometimes I hate PHP!
