We have a situation where we have a primary server hosting OpenInsight 8.x applications for mutliple users. It has UD4 installed.

We also have an OpenInsight system powering a public web server with it's own local copy of the same data. It is essentially read-only, so there is no need for UD4 on it's local data.

To keep the data synchronized, we have a replication system on the primary system that uses an MFS that writes a copy of any transactions on the primary database out to a transaction table on another server. At night a batch process on the web server can look in this transaction table and apply the transactions to it's local copy of the data, and then delete the transactions once they are completed. This all works fine.

My question is this… For security reasons the transaction table is physically located on a different server than the one with the primary application and the UD4. So…. how do I make sure the Universal Driver handles the access to this shared transaction volume located on a different server?

I'm thinking the canned answer is that the server where this shared table is located needs to have its own Universal Driver purchased and installed. This seems like a bit of an overkill since it is only a single table with a few kilobytes of transient data.

What I am really looking for is some good information on how the Universal Driver can be configured to handle different situations. I recall in a talk at a past user conference that it was explained how to set up the UD so users could access OI tables but not be able to even see the REV files.

That is really what I am trying to do. I need to give the web server (and a couple of other things) access to this one transaction table without oping up a big hole from the public web back to the rest of our network.

Can we discuss configuring the UD, or can someone point me to an article on the subject I may have overlooked?

Thanks!

Jim Peters

There is a lot of information to process so here are some ideas to consider.

1) The technique of hiding data is described very well in this recent post from Sprezzatura.

2) If only one oinsight.exe is attaching the data table on a separate server there are no concurrency problems and the setup would be OK. However, if multiple sessions (oinsight.exe or arev.exe) attach and write records then there will be concurrency problems.

3) You could secure the application and the foreign table so only specific users have read/write capabilities at the NTFS file level. Although this doesn't exactly apply to your situation there is an article on how to harden an OpenInsight 9.x system.

4) Build a gateway with OECGI on the remote server that runs only 1 engine. Issue read/write commands through OECGI to the file. This would create a bottle neck and be similar to only having one session attaching the remote server at a time.

The linear hash service (Server side of the UD) can only control files that are on the server's local disks.

OpenInsight 9 includes the Universal Driver as part of the D license. This would provide another UD license for you to use.

Jared,

I think items 1 and 3 are exactly what I am looking for.

Thanks!

Jim

View this thread on the Works forum...