With the advent of 32-bit OI it seems that some of our users will migrate enthusiastically whilst others will be unable to justify the cost of upgrading systems which are entirely satisfactory.

This means we shall have to operate two copies of OI - a 16-bit copy and a 32-bit copy so as to make and test both our own general improvements and clients' requested mods.

Will this be a problem or will we have to run 16-bit OI on one PC and 32-bit OI separately on another?

What would be the implications in trying to run 16-bit OI and 32-bit OI on the same network for the same reasons?

Also, maybe client deployment of OIPI Prof won't match deployment of OI Std and we may need to try to run separate copies at the same time here for similar reasons (maybe even for 16- & 32-bit OI!). Again, would this prove any problem?

Lastly, we haven't installed repository mirroring - we just keep a string of live backup copies on the main HD and on backup media. Is repository mirroring really necessary/worthwhile? Would it work OK with multiple copies on the same PC/network (e.g. 16- and 32-bit OI)?

Advice and comments welcome.

Richard Guise

Richard:

Will this be a problem or will we have to run 16-bit OI on one PC and 32-bit OI separately on another?

I'm not sure I understand- OI16 and OI32 going against the same data on a network?

Mike

Mike

Thanks for your very speedy response.

I'm not planning the different versions running against the same data.

I may well have Clients A,B & C staying with OI16 and clients D,E & F going to OI32.

I will have different apps for each client (inheriting from the core app) with each account attached to that client's sample/test data.

Thus one moment I might start up Client B on a 16-bit OI and then the next moment start up Client E on the upgraded 32-bit copy (not concurrently).

I'm more concerned whether the OI32 upgrade might load different DLLs, etc. which could then screw up the workings of the OI16 copy.

Ditto the OIPI Prof

Ditto any interaction in separately mirroring the two repositories.

TIA

Richard

At the bottom of this SENL article, we explain how to load up a development and runtime system using the same install of OpenInsight. We see no reason why this tactic won't work for OI 16 and OI 32, since it's just the EXE and DLL files that change, just like the development and runtime EXE and DLL files.

Be warned about creating records greater than 64K that won't be readable by the 16bit version or groups that end up with more than 64K worth of keys.

The Sprezzatura Group

World Leaders in all things RevSoft

Sprezzatura,

Be warned about creating records greater than 64K that won't be readable by the 16bit version…

But how are records created? Some programmatically. Some by table bound forms. Some by other processes, like SYSLIST rows, and data from relational indexing.

I don't worry too much about records written by my own code and forms.

But what about records from system processes? How can we keep OI32 from producing records incompatible with OI16?

…or groups that end up with more than 64K worth of keys.

Same question.

- Oystein -

View this thread on the forum...