DougHughes.net

The last few weeks, I have been working to prepare a project for launch. During that process, the client had a new VPS set-up (to be used as ‘production’) and we started to move the codebase to that server and test it to make sure everything is working as expected. Most everything was working, however, there was one section of legacy code where where we started to see a lot of errors on the new server. Going back to the staging server, we were not getting these errors. I was also not getting any errors on those pages when I tested them in my local development environment.

These errors were realted to a column named ‘ROWID”, which, I discovered, is a built in ‘column’ in Oracle that returns a unique value for each row in a database. Its kind of like a UUID, but not nearly as long.

The error messages in question were related to a method , stringValue(), being called on the ROWID column in a query object. When I did a <cfdump> of the query, I could see that the value of the column ROWID was a string. Thinking that the stringValue() method was redundant, I removed it and the pages loaded without any errors. The client was happy and we moved onto other issues.

Here is a snapshot of the <cfdump>:

Fast forward a few days and now that same code I fixed to work on the new server, was throwing errors on the staging server. While they were not the same exact error, they were in the same part of the code. Following the same troubleshooting steps as before, the first thing I did was do a <cfdump> of the query. This time I noticed that that the value of the ROWID was not a string, but a Java object, of tpye ‘oracle.sql.ROWID’. Not surprisingly, there was a method on this object named, stringValue().

Here is a snapshot of the <cfdump>:

So, now that I figured out the problem, and coded a solution (which invovled checking to see if ROWID was an object or not and handling it appropraitely), I wanted to find out why we were seeing different behavior. There are some differences between my development environment, the staging server and production server. They had different operating systems, Mac OS X(me), Windows 2003(staging) vs Windows 2008(production), different editions of ColdFusion, CF8 Developer(me), CF8 Standard(staging) vs CF8 Enterprise(production). On the surface, neither of these shoudl really be the culprit, until we look a litle closer. The biggest difference, and the one that was causing this behavior, was that the different servers were using different datbase drivers for their respective datasources.

ColdFusion 8 Enterprise & Developer Editions ship with native Oracle drivers, ColdFusion 8 Standard does not. On the production server and in my development environment, we were able to use the native driver and it handles ROWID just like any other column. However, for the staging server, the datasource was set up to use the Oracle Thin Client JDBC driver and it handles ROWID a little differently – by returning an object instead of a string.

All in all, a lot of time was not wasted on this issue, but it does bring an important popint to light. When you are dealing with different environments for development, staging and production, you need to be aware of how those different environments might behave – such as what is returned from a query. This is one thing I will be filing away for future reference as I doubt it willbe the last time I see something like this.