Full package and version problem...

[swhitmire]

Ok, I'm really confused. In advance of installing SP24, I built a new full package of the current state of things and installed it on a couple of machines. I then discovered that many (but not all) non-JDE versions don't work -- when I try to run them or check them out, I get the "Version is not installed on client" error. In the debug log, there's a select on F98761, and then an error:

Aug 07 10:30:39 ** 3820/2756 SELECT * FROM PD7333.F98761 WHERE ( RSOBNM = 'R59VERTEX' AND RSVERS = 'DER00001' ) ORDER BY RSOBNM ASC,RSVERS ASC,RSRCRDTP ASC,RSGNCID1 ASC,RSGNCID2 ASC,RSWEVENT ASC,RSGNCID3 ASC
Aug 07 10:30:39 ** 3820/2756 Entering JDB_Fetch
Aug 07 10:30:39 ** 3820/2756 ORACLE DBFetch: Invoke OCI Fetch fetchNumRows = 1
Aug 07 10:30:39 ** 3820/2756 DATAUTILS:JITI for UBE R59VERTEX Version DER00001 failed. Version specs may not be present on server.

Sure enough, there aren't any records in F98761 for that version, or any of the ones with the problem. If I do this on a machine with the old package, though, it works fine, and that select never happens. I assume it doesn't need to do that select if the specs are already on the local machine? Is there always a record for every version in F98761, even if there are no overrides on the version (I think that's what the ones with RSRCRDTP=1 are)? And does that mean that somehow between building the previous full package and building this one I've lost a bunch of records in that table? If so, anyone have any idea where they went (I don't!)?

 

[Terry Duffy]

If I remember your last post you were trying to find out which objects were checked out and where in Object Librarian.

This left you with this issue as versions created or checked out are not listed in the object librarian.

To find out which versions of reports / applications you have checked out use the following sql:-

select vrpid, vrvers, vrmkey, vruser, vrvcd, vrchkoutdat from dv811.f983051 where vrchkoutsts = 'Y';

This will give you something like:-

VRPID VRVERS VRUSER VRMKEY VRVCD VRCHKOUTDAT
---------- -------- ------ ------ ------- -----------
R98OWSECB PSFT PSFT FAT1 107200 0
R98403 XJDE0001 PSFT FAT1 107106 109050

Where VRCHKOUTDAT is 0 it indicates a new version. Where a date is there instead, it is the date the object was checked out. VRMKEY will tell you which fat client and obviously VRUSER who created / checked out the version.

When trying to run a version from batch versions if you can see the version in the list it is there either because it is checked in and available for use OR it was created / checked out by the user ID that you are using. If you go to the form exit and choose the row exit ALL VERSIONS you will see versions that have been created BUT NOT CHECKED IN higlighted in BLUE.

I believe the F98761 records are only created once the new object is checked in. It might be that when you switch back to the old package directories that is picking up the objects in local specs.

You need to review which versions you want to keep and which can be deleted.

Depending on the number of versions you are talking about you can either go to OMW and use the Searh By Object Form exit and search for the object | version and find the project it is in and add yourself as an authorised owner and delete the version from all locations (if new but not saved and you do not want) OR erase checkout (if an existing version).

You could also revert to sql but then you lose any audit trail in OMW logging OR check in the objects (if you can still get to them with the old package directories) and build an update package and deploy.

Hope this helps.

 

[swhitmire]

No, that wasn't me -- I know how to find what's checked out, but that's not the problem. These are checked-in versions in PD that are being used every day, but seem somehow to have lost their F98761 records since the last package -- people with the old full package can run them, people with the new full package can't. Thanks for the reply, though.

 

[swhitmire]

Further info... I wondered if something could have gone wrong with the version copy I did last week from PD to PY, but I checked a backup of the F98761 from before that and it's the same. And I'm now pretty sure there is supposed to be a record in there for every version, since I created a new version with no overrides and it did make a record. So, anyone out there with any thoughts? Assuming that the problem really is that the stuff's just gone, I guess to fix it I'll have to find every version with a record in F983051 but no record in F98761, and then for each of those go to a machine that's got the old full package, check the version out while logged in to PY, then log in to PD and check it in.

 

[BarbKramarski]

How did you do the copy?
Barb Kramarski


In a message dated 8/7/2009 12:02:35 P.M. Central Daylight Time,
[email protected] writes:

Further info... I wondered if something could have gone wrong with the
version copy I did last week from PD to PY, but I checked a backup of the
F98761 from before that and it's the same. And I'm now pretty sure there is
supposed to be a record in there for every version, since I created a new
version with no overrides and it did make a record. So, anyone out there with
any thoughts? Assuming that the problem really is that the stuff's just
gone, I guess to fix it I'll have to find every version with a record in F983051
but no record in F98761, and then for each of those go to a machine
that's got the old full package, check the version out while logged in to PY,
then log in to PD and check it in.
--Scotti Whitmire DeRoyal Industries OW Xe, SP23_R1, U8, AIX 5.3, Oracle
10.2.0.2 <*>

 

[swhitmire]

I used R9830512 to do the copy. And I just checked the PDF again to make sure I really did copy PD to PY and not the other way around.

This was a client-only package, and it built fine, no unexpected errors. I've deployed to multiple clients multiple times (with two different new full packages, actually) and gotten the same results every time.

 

[swhitmire]

Still looking for any advice at all... Oracle hasn't gotten back to me. I did try checking out/in one of the versions as I described above, and that did fix it. So does anyone know of a simpler way to do that, since doing it manually for over 4000 versions is going to take a really long time? I assume the Data Selection Commander and PO Commander Everest sells look at the central objects and not the local specs?

 

[Alex_Pastuhov]

Yes, they mostly look at CO DB (possibly with some exceptions, i.e.: PO Commander looks at local DSTR/F98743 specs for better speed).

It's a nasty problem you have on your hands, I don't even know what may have caused something like this, never seen the like.

Maybe Boomerang can help you a bit: by Exporting (off the local specs, checkout status does not matter) and then importing (again into the local specs, but now marking the objects checked out), you would be able to speed this process up. - You will need to first add all these versions into a Project before you do this (can use SQL for speed). And then you can select the Project after the import back and click "Check In" button once for all versions in it.

The specs, of course, could be copied, but there's no ready tool for this and it's probably not a very easy task...

 

[swhitmire]

Thanks for the quick answer, Alex. If I wanted to SQL the objects into the project, what else would I need to do besides create records in F98222?

 

[Alex_Pastuhov]

Nothing else, really...

 

[swhitmire]

Ok, I'm getting a script set up to insert the records, but I'm not sure about the POOMWPON1 field... most of the 68000+ records have 0 there, but 1150 of them have various long numbers, and I'm not sure what they represent. The data dictionary description is "OMW Project Object Future Use Numeric 5", which doesn't really help.

Can anyone explain what this field is? Thanks!

 

[swhitmire]

Just wanted to let everyone know I got it fixed... wrote a Perl script to take the list of missing versions and insert records for them into F98222 so they'd appear to be checked out to my machine, then checked them in. That one field that I wasn't sure about turns out to be the token queue... for this purpose, 0 worked fine.