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