Hi All

Can someone verifiy that the check out thing won't check out more than 250 something items? For me, this is not quite enough to do source, debug, and exe for two procs, and 6 relatively small forms.

And if you have the feeling of deja vu, how about this:

I tried "check out" without the quotes in the "search this list" it returned no results (unbelievable) because I know I have typed in the very stuff in the subject lines no less eg

http://www.revelation.com/WEBSITE/DISCUSS.NSF/09d90959a1a106db8525652c0042cb86/8A584213C0509DA385256996000B2483?OpenDocument

And has anyone else noticed the discussion forums being unavailable around 8pm New York time? Are the servers kept in California with no UPS?

Mike Ruane: Do you think you could put fixing this kind of thing on your list of things that would be nice to have. Ie I'd like to be able to check out the whole form and all its events, source debug and executable and friends in one go just by typing in the form name instead of having to select each individual component. I'd like to be able to check out 6 forms and two procs this way. Or as many objects as I need. And I'd still like the "no lock" option. Sprezz and I probably have all the code you need to make this kind of thing work. See the thread I linked here to.

Scott, LMS

in little delicate morsels we check out.

Sprezz, I may send the required email soon.

Janet,

I can confirm that checkout has a limit of about that many, and I agree wholeheartedly about checking out of forms and various attachments.

I imagine that the limit has something to do with the size of the record it creates in the SysReposLocks_Temp table in the checkout area.

Simon

RebusHR

Hi Simon

Interesting it would put stuff in a locks file when I tell it not to lock, locking seems to cause more problems than it prevents, especially when I'm currently working solo.

The stuff I have read about deployment so far, suggests that I can "deploy" everything I have changed since date x which is not a good idea since my dev app contains many half complete things and dev tools that I don't want the client to have. The half complete things happen when the client changes priorities before I get a chance to complete.

I figure if it is mostly a matter of copying stuff from various tables to other tables, then I can write stuff to do it. I think Sprezz (Andrew?) already has. I have code that takes a checkout and "converts" it to a SYSUPGRADE, for which I have more code that copies all the components to the various tables the stuff belongs in. All not compatible with no dictionary modifications etc in the latest versions of OI. I have to boot all the clients off their live app and put it in dev mode when I want to add a new item to a dictionary, or even a whole new dictionary. I can't just boot them out of the components I want to update. Still they all go home at 4:30pm so its not too hard to get the system to myself, and I created a bunch of bat files to do the dev-runtime conversions without my typos. Not sure why client should have to have a dev OIengine just so I can upgrade their system. They don't do development.

Scott, LMS

Scott,

Checking out forms is much easier when the forms use commuter functions. Not so much work remembering, figuring out and locating all the necessary items, and not as likely you hit the limit.

You hate me now, don't you?

- Oystein -

PS. Another item on the wish list for a better check out tool must be the ability to locate all components a certain compenent depends on. (Or can it already do that? I don't do checkouts much.)

Hi Oystein

That thread I put a link to has a late contribution by Sprezz offering a tool that finds all the dependants/linked thingys that your item uses.

Converting every form I change at this point to use a commuter would add about a week to every change I make. Not doing it means I can change 3 forms in one day. I have been doing it sometimes. I added one for one of the forms, hence one of the proc's.

And I am still trying to follow what you are doing with that savewarn thing. Like adding another layer to a mille feuille (spelling?). I think I was doing the same thing conceptally with an @var on the Parent frame/window/form thingy.

Scott, LMS

Scott

We moved away from using the Checkout facility early on and switched to the RDK. It works well. Although you can choose to collect everything changed since a given date, you can easily select individual items that you don't want to publish.

Selecting extra items that you do want to publish is a little trickier - but can be done.

1. Use the Runtime Deployment Kit to create a repository view which contains approximately what you want.

2. Go into the System Editor, Open Record, SYSREPOSVIEWS, and choose the name of the Repository View you saved in step 1

3. You can then modify and twiddle what actually gets deployed to your hearts content.

4. Go back into the RDK and actually deploy that view.

Have fun!

Robert

Hi Robert

So from a knowledge of zero on the mechanics of the RDK let me see if this preliminary thought is correct.

The RDK is accessible only from Dev mode of OI.

My upgrade system allows me to apply an upgrade directly through my application menu, and then it records the new version details on the system so I can always check what upgrades I have applied.

The RDK will allow me to do an upgrade module with part of the application instead of releasing the whole application at once (good).

To use the RDK to apply module (part of an application) upgrades at the client site, I need to persuade the client to purchase a "Server Deployment Pack". They will be thrilled (not) since *they* have no problems with my current upgrade system.

How can I tell if they already have this server deployment pack thing?

Scott, LMS

Scott

Sorry for the delay in getting back to you…

I believe the RDK works fine in runtime, so long as you don't want to add tables / database columns etc., although our customers tend to use Dev mode. We add tables quite a lot.

The way I implemented our upgrade system is to have a reasonably static program which calls RDKINSTALL.

CALL RDKINSTALL(Path, AppId)

After a successful installation, I call another program which arrived on the upgrade which contains upgrade notes and does any special fixes I might want to do - such as installing new tables etc., and writes away the version number of the last upgrade etc. Really works a treat.

Our users run the upgrade program as an option from the application menu.

RDKINSTALL is not specifically mention by Revelation as a Devmode only program. But it specifically doesn't work for tables and database columns unless in Devmode. Actually with tables we use Copy_Table as I can't seem to get RDK to do tables automatically.

Hope that makes some sense…

Robert

Hi Robert

I think I like my tool set better, the only annoying bit is the checkout but I think I could write something that allows me to bypass that, ie allows me to select forms, procs and data items including dictionary data (ie new columns), and put them into the sysupgrade format/file. I already have half of that process set up - a routine that copies checkout stuff to a SYSUPGRADE format.

Once I have the selection tool set up in combination with my create/append to sysupgrade table tool, I can use my existing "apply sysupgrade file" system which takes all the entities in the sysupgrade file and puts them in what ever file they are supposed to go in, whether system tables or my application tables. In fact the thing will put stuff into different applications too. I am sure this kind of thing is old hat, it was mostly there when I got here, I just fixed up some of the cosmetic stuff.

I suspect for me that this would be less work than figuring out how to make the RDK work, and writing the tools to go with that.

Scott, LMS

View this thread on the forum...