RE: implied CRTSQLPKG weirdness - uses creator of program as RDB user in creating SQLPKG?

Ok... The consensus solution was to explicitly create an *SQLPKG on the remote LPAR/server. This won't work because the program is never installed to the remote LPAR/server and an *SQLPKG object apparently cannot exist unless it is. I need new ideas.

Here's the deal:

I've a process that will run on a local LPAR/server that will consume data from a remote LPAR/server. The program will only exist and run on the local LPAR/server, never on the remote.

The program uses 3-part naming in its SQL to identify the remote server.schema.table. Because of this, the program will normally implicitly create the *SQLPKG on the remote LPAR/server. In the compile command (CRTSQLRPGI) of the local program object, this *SQLPKG is directed to be created in QTEMP. No reason for QTEMP beyond ease of testing. This will allow the local program to process remote data.

As Charles indicted earlier in the thread, the implicitly created remote *SQLPKG object is created using the object creator, not the object owner or job current user. It doesn't use the profile used to establish the CONNECTION either. Because the object creator doesn't exist on the remote LPAR/server, the implicit creation of the *SQLPKG fails.

Ideas?

Steve Needles

________________________________
This communication, including attachments, is confidential, may be subject to legal privileges, and is intended for the sole use of the addressee. Any use, duplication, disclosure or dissemination of this communication, other than by the addressee, is prohibited. If you have received this communication in error, please notify the sender immediately and delete or destroy this communication and all copies.

TRVDiscDefault::1201