Adventures with ORACLE 10gXE and Windows

Well, the aim was simple enough: to have a go at getting Drupal to run under Win2k and ORACLE 10g Express Edition.

Famous last words? ...

I have an old hard disk gathering dust with Windows 2000, Apache 1.3, PHP 4 and ORACLE 10g Express Edition installed. It's mainly used for laboratory experiments: installing software for the purposes of evaluation and the avoidance of polluting my main Windows environment, that sort of thing. So out comes Mr Eighty Gigabytes and, one download of PHP 5.1.6 later, we're booting up into my throwaway Windows 2000 environment...

Round 1: PHP 5 and Apache 1.3

Installed PHP 5 for Windows from the prebuilt binary distribution available from the PHP web site. It was pleasing to see that php_oci8.dll came bundled along with it. A few simple tests were conducted to ensure that ORACLE connectivity was working fine and I proceeded to install Drupal and OraDrup.

Visited the Drupal front page and discovered that the apache worker process kept crashing. No evidence was left behind regarding the reason why!

The apache worker process kept crashing. No evidence
was left behind regarding the reason why!

So, after some head-scratching and wondering whether the age of the Apache installation was a factor...

Round 2: Installed Apache 2.2.3

Visited the Apache web site and was reminded that Apache 1.3 is rapidly fading away from the scene. Certainly, Windows binary distributions of Apache 1.3 are no longer being made available. Of course, I decided to pull down a copy of their latest stable version of Apache 2.

It was during the process of configuring Apache for PHP5 that I discovered that it would spew forth fire and brimstone every time it tried to load the PHP 5 module during startup. It would say "could not find module" when clearly the module was present. Was this problem privilege-related? Not a chance! I then wondered if, when the PHP documentation says it works under "Apache 2", they actually mean to say "Apache 2.0"? Well, it was true that release 2.2.3 managed to do the job under Linux. Was it worth trying a different "Apache 2" for Windows? Do mouse droppings roll?

So...

Round 3: Installed Apache 2.0.59

Another download of the apache web server later and we have Apache 2.0.59 installed. One short bit of configuration for PHP 5 later and we are ready to go. The ORACLE connectivity tests prove successful so finally, it's Drupal's turn...

Visited the Drupal front page and discovered that the apache worker process kept crashing. No evidence was left behind regarding the reason why!

The apache worker process kept crashing. No evidence
was left behind regarding the reason why! AGAIN!

Well, I was certainly stumped.

So...

Round 4: Zend Core for ORACLE

I suspected something relating to php_oci8.dll was beginning to smell very bad, having been through something quite similar in the Linux world.
Having caught sight of this entry in Alison Holloway's Blog, I decided to use this diversion to take the opportunity to give Zend Core for ORACLE a try. After all, it's specifically for ORACLE and is tried and tested, right? Furthermore, it comes with Apache 2.0.59 as well as PHP 5.1.6, all within its own neatly self-installing and self-configuring package.

One installation of Zend Core for ORACLE later and we are up and running. The ORACLE connectivity tests prove successful yet again so, once more, it's Drupal's turn...

At last! No more crashing worker processes!
BUT, following the creation of the Drupal administrator account, session information seemed to keep getting lost. Once logged in to Drupal, I discovered that the login session would last for just a single page view and I kept getting "Unauthorized Access" messages by the bucketful and endless requests to log back in!

Once logged in to Drupal, I discovered that the login session would last for just a single page view!

By this time I had pretty much had enough of all these shenanigans. It was time to engage the brain a little, so...

Round 5: Pinch php_oci8.dll

I decided to take a copy of the php_oci8.dll library that came with Zend Core for ORACLE - where we had no Apache worker processes crashing - and transplant it, lock stock and barrel to my earlier Apache 2.0.59/PHP 5 installation. At the very least, it would either lend weight or blow away the idea that the bundled version of php_oci8.dll in PHP 5.1.6 was, shall we say, "fubarred".

Installed it in place of its PHP 5.1.6 namesake and.... Drupal finally managed to work! Logged in, set options, created content, previewed content, saved content, viewed content... lovely! Hooray!

Furthermore, the response time absolutely blew me away! It was responding so quickly that I had to double-check to make sure that Drupal wasn't running under MySQL! It was indeed ORACLE that was delivering the goods. Absolutely fantastic!

It was responding so quickly that I had to double-check to make sure that Drupal wasn't running under MySQL!

One small fly in the ointment was discovered shortly afterwards: Drupal anonymous page cacheing is behaving strangely. Turned on the cache, logged out and all was well. The next and subsequent screen refreshes result in a blank page until the cache expires. These symptoms sound very similar to those described in this Drupal post. It was certainly true that I was using Internet Explorer. Perhaps this is a Drupal bug that hasn't yet been fully squished?

At that point I decided to call it a day. At least I had seen ORACLE 10gXE and Drupal shaking hands in the same room! Not bad at all.