upgrade to devClass license (General)
At 16 APR 2008 01:58:36PM S Mecklenberg wrote:
how do we apply a v7.3 upgrade to a v7.2.2 devClass license?
we use split directories between oiworks and devClass licenses.
is there a document of how to apply updates/upgrades to the devClass licenses?
run the update in the oiRoot - but cannot run the update on the spilt directory.
ran into the issue originally when first got the devClass license and install ODBC update.
thank you.
Regards, Stacy
At 16 APR 2008 02:25PM Dave Harmacek wrote:
I just copy the oengine.dll for each license into the OI folder, apply the upgrade and copy the upgraded oengine.dll back to where it began!
If you have separated only the .dlls, then copy the upgraded .dlls as well.
At 16 APR 2008 02:36PM Mike Ruane wrote:
Stacy-
Dave's procedure is the same one we use- I just did it at a client last month.
Mike
At 16 APR 2008 02:56PM Bob Carten wrote:
BTW
With UD 3 or 4 you can use revparam with a share name to allow two sets of binaries (.exe, .dll) to share one set of repository and data files.
To implement:
Have dev, runtime and revboot directories.
Dev and Runtime should each contain everything except .LK and .OV files. Specifically the .dbt and revparam files should be there.
Revboot should be all of the .LK and .OV files in a typical relative path arrangement
Dev and Runtime should each have a revparam like
ServerOnly=1
ServerName=192.168.123.234
TcpIpPort=1234
ShareName=REPOS
The LHService must have a sharename defined, e.g.
REPOS=c:\revsoft\oinsight\repos
I believe that with this configuration you can run either version, upgrade one version then the other, no need to stop oi, copy the dll, restart. In theory you could have sharenames for PROD, TRAIN, DEV databases, just edit the revparam for the different shares to operate on a different set of data. See the LH Installation manual for details.
- Bob
At 16 APR 2008 07:39PM David Goddard wrote:
Bob, Could you hide the REPOS directory from the users altogether?
E.G.
1. oinsight directory REVPARAM with the following settings
ServerOnly=1
ServerName=192.168.123.234
TcpIpPort=1234
ShareName=REPOS
2. Put the actual LK and OV (and revlocks) files in c:\revsoft\data\repos, which the user does not have direct access to.
3. Create registry entry as:
REPOS=c:\revsoft\data\repos
A government user of OI 8.03 is not comfortable with having the oinsight directory with full read/write access. By employing the above technique, can we make the oinsight directory with just the .exe/.dll/.dbt files read only?
They have already used this technique to hide the applications data files form the user, but I didn't think you could hide REVBOOT as well. If so, then this is great.
Any down side to this arrangement? One I can think of is you can only run OI if you have the UD3 or UD4 service running. If for some reason the service dies and/or you need to access OI, you would have to copy the lk/ov files back to the oinsight directory.
What about the oengineservice?
Thanks
Dave G
At 16 APR 2008 10:32PM Bob Carten wrote:
Could you hide the REPOS directory from the users altogether?
Yes, you can have the repository on a separate server with only a linear hash tcpip tunnel, no user rights, not one LK or OV file directly accessible by the user.
I have used:
- a target folder containing dlls and exes;
- a working folder containing REVPARAM, REVBOOT, SYPROG and MYAPP dbt's, a BMPS subdirectory.
- a shortcut pointing to engine in target folder, with working directory set to the working folder.
My goal was to show that I could copy the exe's and dlls to each workstation on a WAN yet share the repository and enforce the license counts. WAN speed was not great, but it worked.
I have not tried running SocketServer this way, but I will have that answer for the Vegas show. It should work. In fact, you should be able to have one or more web servers with OECGI2 or equivalent perl/php/ruby/.net script pointing to one or more separate application servers running the oi socket server, pointing to one or more data servers running UD or U2 filing systems. All inter-connections can be pure TCPIP, you can cross distances or platforms. Using VMWare or VirtualBox you can even host the Windows Socketserver inside a Linux box, still get all this to work. This seems useful. Of course, implementation is left as an exercise for the student.
At 21 APR 2008 09:17AM S Mecklenberg wrote:
thank you, I thought that was going to be the answer, just was hoping for a cleaner way or was wondering if process had changed since I last update.
thank you.
Regards, Stacy