I've just tried deploying a new app using the RDK, etc. as follows :-

1) Deploy full app from 4.0.3

Won't work - REVSHE32.DLL missing

2) Apply 4.0.2 Runtime Upgrade and replace oengine.exe with copy issued by RTI.

Works

3) Apply 4.1.3 upgrade.

"Unable to open the SysreposLanguage file" and crash

4) Discover that the upgrade processing has failed to create SYSREPOSLANGUAGE or SYSREPOSXML. Also that the latter has not been created in my 4.1.3 development copy although the SYSREPOSLANGUAGE has.

5) Copy SYSREPOSLANGUAGE file from my 4.1.3 dev copy to the newly deployed runtime and rename it with GLOBAL account.

"Unable to open the SysreposLanguage file" and crash

6) Inspect both files and their REVMEDIA entries. Only difference is the REVnnnn name.

Any solution - apart from using 4.0.3 instead of 4.1.3?

RTI, help!

Richard,

I'm certain that some attention needs to be given to the upgrade process for runtimes but if you are in desperate need to rollout a 4.1.3 runtime then you can always swap in a development engine, run the upgrade, and then swap back the runtime engine.

[email protected]

SRP Computer Solutions, Inc.

Don

Agreed - if I just had one or two apps.

As it is I've got about 6 basic apps. Each client has their own app inheriting from one of the basic apps - so that I can do the variants they need. After all that sort of facility is one of the reasons for sticking with OI! The RDK updating facilities (as modified here) are magic in keeping them all in order.

I suppose I could simply copy my main development copy and then sit here deleting all the unwanted apps and then replace with runtime engine. However, I just don't think one ought to have to go through such torment because the RDK won't work properly.

Maybe the problem is that I'm using Win 98 and not XP/2000. Maybe the missing DLLs are part of XP but not in 98. I've seen/heard nothing to suggest these sorts of problems with OI and 98.

That's also why I'm developing with 4.0.3 as the 4.1.3 Form Designer is unusable with Win 98 (see elsewhere in the discussion forum).

It then occurred to me that, maybe with the extra respository entries for DLLs in 4.1.3 it has all been sorted out.

So I upgraded a copy of my development copy to 4.1.3 and tried a new app deployment.

No joy! UTF8.DLL missing. Then OTL.DLL said it couldn't communicate with something else, although it was present.

Again, maybe if I try this with XP on my laptop, all will be sweetness and light.

In the meantime, my procedure is to deploy with 4.0.3, copy the oengine to another name, run the 4.0.3 upgrade, delete the upgraded engine (as the upgrade screws the licence) and replace with the renamed one.

This procedure is the only way I've found to get a new 32-bit OI runtime deployment which works!

I then tried then upgrading to 4.1.3 but SYSREPOSLANGUAGE file wasn't created and the logon crashed as a result. So I copied SYSREPOSLANGUAGE from my development copy but the logon said it still couldn't open it - although I can via Arev, etc.

Therefore I'm going to forget 4.1.3 until RTI fix it (or confirm it works with XP)!

4.0.3 seems a good release and I haven't seen any great advantages yet in 4.1.3.

Your comment with upgrade of runtime to OIv4.13. I had similar problems, only resolved by swapping the newly created v4.13 Oengine.dll with full licence and re-running the upgrade, then swapping the runtime back in. Environment XP.

I dare say this and other small issues will be resolved shortly with the forthcomming patch.

Richard

I'm sure I won't be alone in thanking you for this.

I was wondering why my full licence upgraded OK but not the runtime.

Interested it's also a problem with XP. I thought it might just be me being one of the few mean and backward developers still using 98 for development work (see comments elsewhere on Form Designer's relationship with 98). I'll try it here in Win98.

How did you find this trick? Inspired guesswork, burning lots of candles at both ends or a tip-off?

Did RTI know about this problem? If not then clearly they didn't try upgrading a runtime before releasing the upgrade. If they knew, why didn't they tell us and prevent us all wasting our time?

Glad to hear there's going to be a patch.

Regards

Richard

Richard-

I am working on the RDK at this time. In a few days or a week or so there will be a 4.1.3 patch available to Works members in the Works download section that should address most of these problems.

The missing DLLs are my fault. Period. Because of the development environment I use and the test configurations the missing DLLs didn't get noticed.

However, one of the great feature is that if we do forget a DLL entry in the Repository that our developers can add it themselves. OpenInsight doesn't hold you hostage waiting for the next release, as some software companies do.

I've apologized for the missing DLLs before, and I do so again. But, you have the ability to fix this problem yourself.

Mike Ruane

Revelation Software

Mike

Thanks for your reply.

I'm sure we'll all be pleased to hear that a patch is on the way.

In the meantime I've done a bit more in this area.

It seems that all works well if one upgrades a runtime by temporarily substituting a development oengine.exe for the runtime oengine.exe and then renaming the oengine.run.

However, one has to be a little careful from 3.7.x to 4.0.x in that the runtime licence is removed and then the 4.1.x upgrade won't work.

If one is upgrading an existing multiuser runtime then it is necessary to do an extra separate upgrading with the runtime oengine.exe in place in order to keep the licence straight and then move the upgraded runtime oengine.exe into the copy upgraded with the development engine (instead just renaming the oengine.run).

Richard Bright seems to have done something with the 4.1.x upgrade by shifting the oengine.dll around. I didn't seem to need to do this.

in this context, Mike, can you confirm that in 4.1.x the licence information still resides in oengine.exe and that oengine.dll has no licence implications and is the same for development and runtime copies?

Confirmation of this point would be very helpful in the sort of self-help situation you describe.

Regards

Richard Guise

Richard,

in this context, Mike, can you confirm that in 4.1.x the licence information still resides in oengine.exe and that oengine.dll has no licence implications and is the same for development and runtime copies?

As of 4.1.x all license information is stored in Oengine.dll. Oengine.exe is merely a shell and does not change when SDP's are applied.

[email protected]

SRP Computer Solutions, Inc.

Richard,

I was reading your posting and as you made mention of problems regarding the 16-bit runtime upgrade, I thought I would clarify one point.

The upgrade from 16-bit OI to 32-bit OI only works on Development copies of OI. It is not made to upgrade on runtime copies of OI.

The runtime upgrade of 16-bit OI will not upgrade with your user count intact. It was designed this way due to the fact that the upgrade of multi-user runtime systems from OI 16-bit to OI 32-bit is a paid upgrade. If you are running into problems because of this, please contact your local Revelation representative (in your case [email protected]) and he will be able to help you with this.

Kevin

Richard,

Kevin and Don have clearly answered issues about upgrading 3.x to 4.x (which reqire contact with RevSoft for the runtime licence re-issue) and the change from executables to dlls in version 4.1. (The move to dlls enables better performance, stability etc).

To be fair to Mike this hiccup on runtime upgrade was missed by all the beta-testers - everyone was concentrating on development systems. Its the kind of problem that occurs when repeated testing is done and you miss the fact that somewhere in the process a table or file was added. Only when you move to a virgin system that the oversight emerges. Having done so much work with the new version and upgrade, I had so much confidence that I didnt bother to do the usual backup at the client site. Bit embarrasing for a few minutes while I thought about how to a field rescue of the situation.

RevSoft have spent a lot of time seeking to take the wrinkles out of OI in this v4.13 and with the forthcomming patchs will undoubtedly be one of the most bug free OI Versions released.

BTW should encourage you to mighrate to XP - heaps better than Win98se for speed and everything else.

Richard Bright

Kevin

You've missed the point!

I got all our 16-bit users upgraded to 32-bit with the help of replacement paid-for oengine.exes. No problem!

My recent problems were quite simply :-

a) deploying new single-user 32-bit runtime copies using the RDK - as it simply didn't deploy all the necessary DLLs. Hence the need to replace the runtime oengine.exe with development, rerun the 4.0x upgrade to force the DLLs to deploy and then put the runtime oengine.exe back again.

b) upgrading single runtimes from 4.0.x to 4.1.x which seemed to suffer similar problems.

In the light of this I haven't dared to try upgrading any of our multiuser 4.0.x users to 4.1.x yet. Hence the question about where the licence count resides. In the light of Richard Bright's response I'm frogging glad I didn't!

Having said this I archive and upgrade clean and development copies each time I upgrade. Ditto client implementations. Also to be safe I have an impressive library of oengine.exes as, if a client manages to delete or corrupt their own copy and can't find a backup (yes, it's actually happened!), I can ride in like a shining white knight, etc., etc.

Seems I'll now have to open a new library archive for oengine.dlls

Thanks to all for their help.

Richard

View this thread on the forum...