Monday, February 2, 2009

Revelation G? You have what???

FusionWare Corporation has products and people with a long history of supporting connectivity for all sorts of unusual platforms and databases. In addition to other solutions, we have a suite of middleware products for legacy, non-relational database systems that are referenced as "MultiValue". We have ODBC, JDBC, OLE DB, ADO.NET and other types of drivers for these systems. We let you connect these systems to just about anything.

Furthermore, these systems come in many different flavors, which run on many different hardware/OS combinations. We can support just about any flavor of these databases. They are a lot like the old Business Basic systems, where it seems lots of vendors licensed (or stole) their own version of the software. Most of these systems have modern, state-of-the-art variations, with rich connectivity options. Occasionally, though, we run into a dinosaur.

Recently, we had a call from a company. They were switching small doctor's offices from a competitor's old DOS-based package to their new Microsoft package that used SQL Server or MS Access and Win Forms to provide an application for these clinics and doctors. The old application did not include source code, and the original vendor appeared to have gone out of business (or was uncooperative with the customer trying to move away from them). The real problem was that the version of the database that they were using was one that was over 20 years old!

The database was a MultiValue variation called Revelation. The DB vendor got up to version G.2 before they made their first major, compatibility-breaking change to something they called "Advanced Revelation", sometimes called ARev. They've moved on to other names since then. A lot of users had apps that worked fine with Revelation version G, but needed a rewrite to work with ARev or later. The biggest change was the Rev G assumed a green-screen GUI, based on the DOS command console, while the newer versions assumed Windows as the GUI.

Now, most versions of MultiValue databases were designed to run on mini-computers (remember those?) and as such were multi-user systems. Revelation was designed to run on DOS-based PCs. They could use a shared Novell-based file-system, but the selling point was low-cost personal computers. Also, they tended to be really easy to run and maintain on a single user PC basis, which is how most small clinics and doctors offices used this particular app. Because of the low cost, they lent themselves to inexpensive applications. There just wasn't the money in upgrades. There also weren't any particular reasons to upgrade these users.

In short, it's not that unusual for someone to have an old app that they've had for a long time, that still runs on this system. What is unusual is for a user or vendor who wants to move them off to figure out that it's a MultiValue system they are working with. Even more rare is for them to actually find someone who knows what it is, let alone can work with it!

Anyways, we got this call. A vendor who wanted to move a customer had run into this system and wanted to know how to get the data off. Could we help them?

Well, this variation is different enough from the other multi-user versions, and rare enough that we weren't going to create a full-blown ODBC or OLE DB driver for it, but we did come up with a very cost-effective way for a user to create an ASCII delimited file of their data.

I actually was able to find an old copy of the 5 1/4" floppy-based Revelation Developer system. (I have both a developer and run-time license of Revelation G.2 - boy am I a dinosaur!)

The upshot was a Revelation-BASIC program, along with instructions to import it into your application and run it, that read a local O/S file and used it to read in and process the data that was of interest to you.

We had to work through some interesting limitations. It turns out that although the application can access the windows file system, it is limited to about 32K for a single block of data. So we had to create blocks of rows and concatenate them later into a single delimited file.

All this was done in a clean, reusable package. This vendor can now resuse this package to convert data from any of their competitor's systems to their application. The same package could be used to copy data to SQL Server, Microsoft Excel, or any number of other sources.

Another satisfied customer. Another interesting challenge met!