Hello all:

We?re in the process of deploying some very beta-ish copies of our OI 3.7.5 application for the first time (and yes, 32bit *is* in our future, but for today…) We?ve had mixed success with APPBACKUP so the plan is to:

1) Delete source code from SYSPROCS by aliasing over from AREV, SELECTING all rows with our appid, then deleting those rows (Will this work? Is there a better way to do this within OI? Is source hiding anywhere else?)

2) Install any necessary SDP?s

3) Rebuild all system indexes, synch everything

4) Re-name the OENGINE and REPORTER executables to their run-time equivalents

5) Winzip the whole app and then have users unzip at their site

6) Have users run the client install that is found on the rev web site

Anyone see any problems?

S/LIST - OIPI are incorporated into our application as well. Can anyone give us pointers on how to deploy those pieces? We have them installed in our master development copy, but we?ll need to purchase a variety of single, 3-user, 5-user flavors of S/LIST. Will those need to be installed separately at each client site, or can we install them all here as part of our deploy first?

Any tips at all would be *greatly* appreciated.

Thanks,

Mike O.

Mike

We can happily provide a list of components that need to be deployed

1) to allow users to create reports

2) to allow users to RUN reports

the former obviously requires a development license, the latter is free of charge (altough obviously the users cannot in any way change the output format).

If you drop us a line at [email protected] we'll ensure you're sent the list. A big gotcha is always forgetting to deploy some structures native to OI that lack repository pointers!

Normally we deploy using an Installshield setup script but as it is early days for you we can understand your reluctance. However once the script is written it doesn't take much to keep it updated with new releases! In fact for S/List we have an automated OI window that collects the release, copies it into the right place, numbers it and updates the Installshield script!

Have you tried to use the RDK to deploy? It works quite well these days, especially if you ensure that all needed SYSREPOS entities exist.

Source is also hiding in SYSREPOSEVENTS if you haven't used quickevents to call a commuter routine.

The SDP needs to be applied AFTER then renaming of runtime components.

If you need any further help just holler!

The Sprezzatura Group

[i]Celebrate CeBIT with Sprezz Local![/i]

Mike,

I just want to echo Sprezz's comments, especially with regards to using the RDK versus APPBACKUP. We got into the habit of maintaining a full application RDK for every app that we support. That way we can create a new application in a fresh installation of OI at a moment's notice.

The only limitation with the RDK is with deploying tables. I would recommend doing that separately. Don't go for the Full System or Application deployments. Just use the Upgrade/Module to handle your needs.

[email protected]

SRP Computer Solutions, Inc.

Hello Don:

We've actually tried the RDK as you and Sprezz have suggested for our entire application, but when setting up our repository record we get a 'too many items to display in listbox' message (even without choosing to deploy tables), which then leads to a host of other problems - usually a GPF.

I think the RDK will work great for us for distributing smaller upgrades and patches. But for a new, out-of-the-box install, it seems to me like we need to go the route we outlined previously (which was actually suggested as an alternative by the Rev/Win-Win folks), unless we're really missing something.

What triggered this whole issue is…

As an in-house test we took our entire app, followed the steps outlined previously and copied it to a different PC here in the office. This triggered all sorts of missing .dll, .ocx messages. Sure, we could probably (eventually) patch together something that works by manually copying all this stuff in, but obviously we don't want to put our clients through that.

Thanks for your input,

Mike

Ahhh the OIPI/Rev client install so you can register OCXs etc….

The Sprezzatura Group

[i]Celebrate CeBIT with Sprezz Local![/i]

Mike,

We've actually tried the RDK as you and Sprezz have suggested for our entire application, but when setting up our repository record we get a 'too many items to display in listbox' message (even without choosing to deploy tables), which then leads to a host of other problems - usually a GPF.

Wow, I've seen some fairly large applications but none that ever produced that message. Just out of curiosity, are you doing a lot of scripted events rather than using QuickEvents and commuter modules to minimize the number of components? What is making this application so big?

I think the RDK will work great for us for distributing smaller upgrades and patches. But for a new, out-of-the-box install, it seems to me like we need to go the route we outlined previously (which was actually suggested as an alternative by the Rev/Win-Win folks), unless we're really missing something.

Truth be told this was our de-facto way of creating a first-time installation of our OI applications. In fact, because we posted this solution so many times in the past I've been told by other developers that they affectionately call this the "Bakke" method of deployment.

[email protected]

SRP Computer Solutions, Inc.

View this thread on the Works forum...