Hi All

I have had this problem before and I nearly made it go away, but not quite enough.

I usually apply updates to client systems using Check-out/new check out/copy from blah blah

Except one system has stuff associated with it that got locked when it was checked out. Which of course is the stuff I need to update again.

So initially I got errors like

"REP803: Entity NEIS*STPROC**CR005 is checked out by the current

]user"

So I made and ran a program which cleared all the field 22 flags from 1 to 0 in the sysrepos table.

I cleared sysreposlocks and I rebuilt the system indexes.

So now I get the error (when I try new check-out/copy from) when I click on select entities

"There are no check outs for the current user"

And yet I have logged in as user NEIS and all the entities in my check out tables (eg SYSPROCS_TEMP) have NEIS all over them and no other ID. NEIS is the app name too. I don't know why I'm stuck again. I really need to clear all the check out control flags somehow so I can check out check stuff in.

Any ideas?

Scott, LMS

This means that the checkout you are trying to checkout FROM was created by a username other than the current username.

The Sprezzatura Group

World Leaders in all things RevSoft

gedmunds@ab

I had the same thing happen to me. Somebody sneaked into my office in the middle of the night and checked out a lot of stuff - a bottle of Lagavullin, an Alessi espresso maker and my very best GOTFOCUS handlers.

- Oystein -

Don't you just hate it when that happens? Well, a Glengoyne in my case but…

The Sprezzatura Group

World Leaders in all things RevSoft

These mysterious nightly users surely have good taste.

- Oystein -

Hi All

I rocked up to car shop specifically to take a car for a test drive and when they asked for my licence I found my card wallet including licence had checked out. It was in a different bag at home. My usual.

In this case however, I checked out the programs and forms and I only know one user id for this app and it is NEIS. The only other way I know how to get into it is with SYSPROG and I can't check out the entities I want because they are associated with the NEIS app. Yes, just to confuse me, the app names and the user names are the same and as far as I know SYSPROG is not a valid user id for the NEIS app and vice versa.

So I have a bunch of check out entitites that think they belong to AP=NEIS, UN=NEIS (I assume because I don't know where to verify this), and when I log into the NEIS app with the NEIS user id at the client site, the Checkout system doesn't match them up. How can I fix this???

Scott, LMS

Who recommends checking out "The Bank" starring Anthony Lapaglia…

Scott

Sorry if we're in egg suck territory but you do know not to use check in, but to use Check Out both to get it off your machine AND to check it onto the client machine? ("Check out to" to get it off yours and "Check out from" to bring it onto theirs?

The Sprezzatura Group

World Leaders in all things RevSoft

Hi Sprezz

Got it in one. I use Check out | new checkout | to which puts stuff into a folder I imaginatively call check_out. Normally I run a process after that called CONVERT which I point at another folder called UPDATE which makes a SYSUPGRADE table in the UPDATE folder and copies all the check_out stuff into SYSUPGRADE. I then have an update process which my users could run which when the update folder is placed within their reach, they can point at and run the apply update process, to put the updates on.

This system will allow me to put on data dictionary changes, and data records and all sorts of stuff, that apparently you can't do with the deploy system. Although sometimes we do have to use dev mode anyway.

In the mean time the particular app with the (ex) locked stuff doesn't have the apply upgrade forms on it (yet). So I have to put the app into dev mode and check stuff into it. Normally(?) this is done at our office and then we give the poor client a whole CD each time we do an update. I find that practice somewhat inefficient especially as this process usually overwrites a folder that contains stuff related to an interface to another application, ie it breaks things.

I only know the way I was taught, and the new checkout stuff, so long as you remember to uncheck the lock, doesn't cause problems with entity already checked out and user has no entities to check in, etc.

Hmm, I just tried the Checkin option and it crashed OI - very nice. Anyway if you are making something to give to a client, why use check in? When I am trying to "check in" something at a client site, it doesn't work anyway.

You want to know how I got my updates on in the end?

I attached my Check_out folder, and discovered that a whole lot of *_TEMP files were attached. Then I rather wickedly copied the contents of the *_TEMP files to their corresponding * files (with unconditional overwrite). I also copied data record which I had previously copy_row_to_os. This all seems to have worked fine. (OI 3.2) And I can hear you screaming/laughing from here.

And I have no clue how to get updates into AREV apart from copy to dos and back. Most of the instructions I have found tell me how to deploy the whole application and usually I only want to change one program. Strikes me as overkill.

I've been thinking about creating a system which will let me pick a form or stdproc and copy all related things, appropriately named to SYSUPGRADE directly, rather than have to go through the rather tedious process of chasing down events and blowing 256 item limits in the check-out entity selection process. But limited future for the OI apps at the moment (in my current employment only) plus the fact that I have been moving to commuter procs, somewhat counter balances the need for this right now.

Scott, LMS

apprentice granny

Hi Scott

]I only know the way I was taught, and the new checkout stuff, so long as you remember to uncheck the lock, doesn't cause problems with entity already checked out and user has no entities to check in, etc.

]I've been thinking about creating a system which will let me pick a form or stdproc and copy all related things, appropriately named to SYSUPGRADE directly, rather than have to go through the rather tedious process of chasing down events and blowing 256 item limits in the check-out entity selection process.

I think this subject also came up in a post a few months back. Deploying Upgrades under "Deploy Application" and installing via RDKINSTALL works fantastically. At last count, we had published (on our website) about 75 upgrades over about a two year period (almost weekly). We always used the "Entities changed since" option (Repository View) and the deployment type is always Upgrade / Module.

I would suggest having another look at this approach - got to be better than using that yucky checkout thing :(

Robert

Hi Robert

So will "entities changed since…" let you be a little more selective, ie I often work on several things at once. Some of them are in a semi-broken state, which I certainly don't want to inflict on clients.

Although I guess this doesn't apply to the app that I am having trouble with deployment. I could try the RDK stuff for that one.

Scott

View this thread on the forum...