We receive files from various sources around the state during a nightly
process and use those to build a new version of production files into a
'work' library; when the rebuild process is finished, the live library is
renamed to a backup (just in case) and the work library becomes the live
library. Wasn't my design, but one I must work with.
Paragraph 2 went completely over my head :)
And good idea on making a SAVF copy of the object...
Tom
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Saturday, June 04, 2011 12:29 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: MSACCESVBA *SQLPKG in a user library - can I remove it?
On 04-Jun-2011 09:57 , Tom Hightower wrote:
Working on getting our new v6r1 system up and going.
One of our daily processes is to rename one of our production
libraries;
Ugh! IMO that process should be rethought. Anything "production"
should almost never have that fate.
when I tried to do it, I received the following error:
Message ID . . . . . . : CPF2136
Date sent . . . . . . : 06/04/11 Time sent . . : 11:52:44
Message . . . . : Renaming library PRODFILES failed.
Cause . . . . . : Library PRODFILES cannot be renamed because it
contains one of the following object types.
-- CRG -- DTADCT -- JRN -- JRNRCV -- SQLPKG -- SQLUDT
Recovery . . . : Either try renaming another library or delete the
objects of the types listed above and try the request again.
I searched and found this object: MSACCESVBA *SQLPKG in the library.
Can I delete MSACCESVBA from this library, and will it be recreated
the next time one or our power user runs something that needs it?
By that naming, I believe the package can be deleted with little harm,
but I can not be sure. A package that exists for Extended Dynamic generally
can be deleted by DLTSQLPKG with little concern, such that the application
that generates the package and adds statements will typically just do that
again on the next connection. Packages created for other reasons may not be
so forgiving to the application dependent on the missing SQL Package; e.g.
from CRTSQLPKG to create the package on a remote RDB.
The "package location" information [DBXPLOC of QADBPKG, or LOCATION or
PACKAGE_CATALOG of SYSPACKAGE] will indicate 'QSQPRCED' for those which are
created by the Extended Dynamic API, and either the *LOCAL RDB name or a
remote Relational Database name for the others.
As a "production" library, that library name will obviously exist again
after the RNMOBJ of the *LIB, so preceding the delete of the *SQLPKG object,
a SAVOBJ can be taken [best to include private authorities] to make a backup
copy of the object, probably best into a *SAVF in the library to be renamed,
from which a later RSTOBJ can be performed into the new version of that
library name. The effect from that, for whomever or whatever access the
*SQLPKG, would be about the equivalent of never having renamed the *LIB.
Regards, Chuck
kwds: RNMLIB
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
