Deploying 32-bit OI (OpenInsight 32-bit Specific)
At 12 MAR 2003 11:53:07AM Richard Guise wrote:
Earlier versions of 32-bit OI wouldn't deploy as, it seemed, some essential new DLLs, etc. didn't have repository entries and therefore didn't deploy.
Has this been fixed in ver 4.1.3?
TIA
At 15 MAR 2003 05:58AM Richard Guise wrote:
Having had no response from RTI or anyone else, I'm reposting this in the hope …
Earlier versions of 32-bit OI wouldn't deploy as, it seemed, some essential new DLLs, etc. didn't have repository entries and therefore didn't deploy.
Has this been fixed in ver 4.1.3?
TIA
At 15 MAR 2003 06:56AM Oystein Reigem wrote:
Richard,
Thought I saw a posting from Revelation about some versions of both 4.1.2 and 4.1.3 having had this problem. Presumably the early versions of 4.1.3 they uploaded to the Works site had the problem, with the error corrected in later versions. But I haven't tried to locate that posting, so I don't know. My memory might be playing tricks on me.
- Oystein -
At 15 MAR 2003 01:45PM Donald Bakke wrote:
Richard,
I understood your question to be about the RDK and whether or not the Full System or Application deployment types are working. If so then from what I've seen there is no difference in 4.13 than from previous versions of OI. That is, it works no better or worse.
At 16 MAR 2003 06:42AM Richard Bright wrote:
Never! Well not when I have similar recollections.
Was it something to do with Table copy?
Anyways RevSoft presumably use the RDK for the System upgrade, and we expect THAT to work without problem.
At 18 MAR 2003 11:16AM Richard Guise wrote:
Sorry, folks, I was vague.
I mean full deployment - i.e. to make a new standalone single user runtime copy that works.
As mentioned it used to work fine on 16 bit but when I tried on 32-bit quite a few of the new DLLs, etc. didn't deploy as there were no repository entries for them. Ergo new runtime copy didn't work.
I notified RTI and heard nothing.
Still nothing …
Do I assume that even 4.1.3 still has the same problem?
RTI, answer please!
P.S. Re using RDK to update client apps, it's just as well RTI have released the RDKMODULEINSTALL code as the issued version is unusable for real life situations. I've had to add command post-processing after record copying (as well as the existing pre-processing - after all one can't install an index on a field until it's there!) plus additional commands to install, remove and update indexes and MFSs and to clear file. Also options to omit DBT update, protect local dict index fields, use current app id, use current attach paths and just a few other additions. I'm not sure RTI licencing would allow me to release my sooper-dooper version, even if for free!
Also, emailing a volume of SYSUPGRADE files to a client isn't the most friendly way of sending an update. Hence I Winzip them and my loader unzips them before running the %RUN% - but the self-extract .EXE is best - but MS Outlook won't save EXEs - hence I'm about to send as .TXE to get round this with my loader renaming and executing the self-unzip.
I'd be interested in hearing what other developers do about these and similar brain teasers.
At 18 MAR 2003 05:03PM Richard Bright wrote:
Richard,
The RDKModuleInstall provides a framework to do deployments. IMHO there are a number of features that could be enhanced or be better exposed. However I am grateful that RevSoft make the source available so that we can 1) understand the logic 2) adapt / build on for our own purposes.
At one stage a developer section was available on this web site to post code enhancements / extensions. Perhaps because of the 'over-the-top' requirements controlling submissions, it was not patronised. Indeed, I only recall one post - from Mike Ruane as a client of RevSoft!
I would encourage you to forward any contributory code that you feel of value to the community thru to Mike and his team. I know that they welcome constructive comment and ideas. But recognise that their first priority, in modifying or introducing new code to the code base, is to protect the community from changes that might break applications. Also Ira - on documentation - would love to get useful subroutines and snipits of code to improve, expand the documentation and to help build a 'How to do it..' section of documentation. Email Ira Krakow at [email protected].
Richard Bright
BrightIdeas New Zealand
At 19 MAR 2003 05:34PM Donald Bakke wrote:
Richard,
I mean full deployment - i.e. to make a new standalone single user runtime copy that works.
Again I'm not entirely certain I know what you are talking about. We create new standalone single user runtime in OI32 the same way…but not with the RDK's "Full Deployment" type. If you had success with Full Deployment in OI16 but not in OI32 then I'm not sure what changed for you. We never had success with OI16.
Also, emailing a volume of SYSUPGRADE files to a client isn't the most friendly way of sending an update. Hence I Winzip them and my loader unzips them before running the %RUN% - but the self-extract .EXE is best - but MS Outlook won't save EXEs - hence I'm about to send as .TXE to get round this with my loader renaming and executing the self-unzip.
Try this link to fix your Outlook problem:
http://www.slipstick.com/outlook/esecup/getexe.htm
I'd be interested in hearing what other developers do about these and similar brain teasers.
For a very professional approach towards loading your RDKs you can use InstallShield. This is what Revelation, Sprezz, and SRP (on occasion) use.
At 20 MAR 2003 01:07PM Richard Guise wrote:
Don / Richard
Thanks for the comments and suggestions. The RDK really should do the job it is purported to do without one having to use InstallShield, etc.
1) Yes, I did manage to use the full app deploy in OI16 to generate runtime copies which worked (although one had to disable any deployment of data files to avoid problems). With OI32 it seemed they simply didn't update the deployable repository records to include the new DLLs, etc. Hence they didn't copy. Hence the runtime copy didn't work.
I've compared the 4.1.3 DLL part of the repository with 4.0.3 and there are quite a few changes - so, even though not in the readme, hopefully RTI have now fixed this. We'll see.
If not, I suppose one could just full app deploy and then run the upgrade to complete the unfinished work.
2) I don't think I can really ask my clients to go round tweaking all their copies of MS Outlook as the excellent refs your link provided - not least that would remove their protection against unwanted EXEs, which their IT depts might not permit. I think my .TXE and rename is probably the simplest and safest.
3) My own adjustments to RDKMODULEINSTALL are a bit untidy - but if I tidy them up some time or someone twists my arm ….
Richard Guise
At 20 MAR 2003 09:43PM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
Richard,
The RDK really should do the job it is purported to do without one having to use InstallShield, etc.
I don't believe Don was implying that you *need* Installshield to do the job of the RDK, or that by using it we are somehow working round an RDK bug. The RDK's job is to provide a means to select and export your application components and move them into a target application and hey, that's what it does.
Installshield is a way to *deliver* your RDK app/upgrade to an end user in a fashion that they will hopefully find familiar - ie looking like 99% of every other Windows program installations out there.
In our experience Installshield routines are nothing more than an nice way of calling RDKInstall().
World leaders in all things RevSoft
At 21 MAR 2003 12:26AM Donald Bakke wrote:
Sprezz,
I don't believe Don was implying that you *need* Installshield to do the job of the RDK…
Spot on! Was just about to say what you said but you got there first.