One of our favourite pastimes is spending time on client site being challenged to do stuff we've never even considered doing before. This post documents the result of one such challenge.

For the longest time, Revelation products have not allowed two volumes with the same name to be attached at the same time. To ensure that index transactions are applied to the correct bang file, the system enforces this artificial limit. Note though, that it IS an artificial limit, implemented at the table attaching level, not at the table opening level.

Many VARs working with multiple clients frequently just copy a base subdirectory of application tables to a new folder for a new client and in so doing, duplicate the name in the REVMEDIA map. This, naturally, means that if we have say an INVOICES table in that subdirectory, that we would not be able to consolidate across multiple INVOICES tables without first detaching the old table and attaching the new one.

This introduces significant overhead.

We needed to find a way of opening the same table multiple times for reporting purposes. Note that caveat - we didn't want to write to the file, we merely wanted to be able to read from it. As that is the case, we just needed a simple raw file handle - with no mention of SI.MFS or any other MFSs - just an RTP57 file handle.

For our first proof of concept, we manually created a file handle and were able to show that we could read from multiple tables having the same table name and the same volume name. After all, a pure file handle doesn't include the name of the table in question, it just contains information about the DOS file name of the underlying file. We did, however, notice that, whereas in the dim shrouded mists of antiquity the file handle used to contain the modulo of the file, it now contains a sequential number representing the order in which the file was opened. So our concern was that if we built the handle ourselves, the system might not know that we'd used a sequential number ourselves and that it might subsequently introduce unexpected consequences.

So, we cast around for a better way of creating a file handle, and unsurprisingly settled on making direct calls to RTP57A to do the heavy lifting for us.

The actual task is relatively simple; given the name of the table that we want a handle for, and the location, return a working file handle. So in RTP57 terms, open the media map, read the row corresponding to the table we want the handle for, grab the DOS file name and request a file handle.

With the process defined, it was not rocket science to create a function that returned a file handle given a location and a table name. The results are presented below.