We have a client that is moving off our OI system to a competitor using SQL. (Silly people…)

It appears the competition went out and bought a copy of OI-Works

and is having the client send them their rev????? files to bring into their SQL system.

Can they simply open their copy of OI, attach those tables and see the dictionairys? Could they feasible overwrite the SYSPROCS table

and see code?

Bruce,

Can they simply open their copy of OI, attach those tables and see the dictionairys?

Yes.

Could they feasible overwrite the SYSPROCS table and see code?

That depends, is their source code in the client's copy of the application? If so then yes. Did you have any agreements with the client to prevent this?

[email protected]

SRP Computer Solutions, Inc.

Thanks Don.

We are trying to find out if the database layout is 'intellectual property' as well as any source in the dict's.

Source in the dicts will be covered by IP. Data is likely to belong to the client - otherwise ODBC drivers would never work on other packages. It will all come down to your license regretfully. As we'll doubtless hear in New Orleans where there's a talk specifically on this area. However best of luck.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

This may not help you for this client, but for the future, you could put an encryption mfs on the data files - even a simple hex conversion would do the trick. Your competitor would be able to attach the data files to their copy of OI but they will receive a SYS1000 error message and be unable to read the data. The mfs is stored in your application and your client should not be able to send your application files without violating your software agreement.

I submitted before I finished my post:

I never tried to put an MFS on a dictionary file to encrypt the source code but in theory it sounds like it would at least protect your symbolic source code and prevent access to the dictionary file without the application files. Has anyone done this?

We use an encryption algorithm mfs because we have sensitive data and rev files are largely viewable with notepad. We haven't started using the ODBC driver but I assume that it would accomodate the MFS -am I correct?

Sandra,

Fton an ignorant peasant's point of view the compatability of the mfs with odbc would depend on the positioning of the mfs in the chain - typically it is inserted near the beginning of the read logic so that by the time it gets to odbc the data is un-encripted. Again, it depends on WHAT you are doing in your mfs.

Thanks for the replies everyone. Hopefully I will be able to catch that discussion in New Orleans.

Wow, this reminds me of a trick I used in RevG (not my invention). In order to speed up the processing (8088 processor days) the formula in the dictionary had only a $INSERT statement. This reduced the size of the dictionary record. All source code was in a separate file that was only referenced at compile time.

Guess this would work to keep the source out of our "modern" dictionaries, too.

Dave (still have a customer in RevG using that trick)

View this thread on the Works forum...