StarQuest Technical Documents

Common StarSQL Error Messages

Last Update: 19 May 2021
Product: StarSQL
Version: 5.x
Article ID: SQV00SQ030

Abstract

This technical document lists the most common error messages when using StarSQL.

The following errors are discussed in this document:

Solution

Not authorized to object <userid>.QSYS2 type *SQLPKG
Not authorized to object <userid>.SWCATPKG type *SQLPKG
Not authorized to object <userid>.SYSIBM type *SQLPKG
Not authorized to object <userid>.SWRC0000 type *SQLPKG
Not authorized to object <userid>.SWNC0000 type *SQLPKG

Problem: The user attempted to use a StarSQL SQL package that he or she does not have permission to use or execute.

Solution: The DBA must grant the user permissions to run/execute the StarSQL SQL Packages. We recommend that use/execute access to StarSQL packages be granted to PUBLIC. For more information about the StarSQL static packages, see the StarAdmin Help or the StarSQL Help. Also see Binding StarSQL Packages Using StarAdmin or or How to Bind Packages with StarAdmin Classic.

Return to the top

Error reported by server during bind of package.

If your database is on DB2 for i (iSeries):

Problem: The user does not have permission to bind the StarSQL packages in the library specified in the Package Collection Name field or the package already exists.

Solution: If you are using StarSQL for the first time, we recommend that you use StarAdmin to bind a complete set of packages. Refer to the technical document How to Bind Packages with StarAdmin for instructions.

Otherwise, check with your DBA to ensure that you have permission to write to the library specified as the Package Collection Name in your StarSQL data source configuration. If you already have packages in this library and you need to rebind them, drop the packages first before attempting to create new ones.

If your database is DB2 for z/OS, DB2 for VSE & VM (SQL/DS) or DB2 for Linux, UNIX, and Windows:

Problem: The user does not have permission to bind the StarSQL packages in the collection specified in the Package Collection Name field or the package already exists.

Solution: Check with your DBA to make sure you have CREATEIN and BINDADD authority on the package collection specified in the StarSQL data source. If you already have a static package, drop the package first before creating a new one. For more information about the StarSQL static packages, see the StarAdmin Help and the StarSQL Help.

Return to the top

Object QSYS.<userid> type *COLLECTION not found (DB2 for i)

Problem: The catalog qualifier specified in the StarSQL data source configuration is not a collection.

Solution: Specify a collection in the StarSQL data source setup or change the catalog qualifier to QSYS2.

Return to the top

Database server <database server name> not found.

If your database is on DB2 for i (iSeries):

Problem: The Database Server Name specified in the StarSQL data source setup for DB2 for i does not match the relational database directory entry.

Solution: Check the relational database directory entry using the command WRKRDBDIRE. If no entry exists with a location of (*LOCAL), add one.

If your database is DB2 for z/OS, or DB2 for VSE & VM (SQL/DS):

Problem: The Database Server Name specified in the StarSQL data source setup for does not match the relational database name on the host.

Solution: Verify that the value in the Database Server Name field of the StarSQL data source setup is the host's DDF location name. For DB2 for z/OS, the database server name can be found by running the VTAM change log inventory utility (DSNJU003) or through panels by using DSNTIPR. The line will look like this:

DDF LOCATION= SYDNEY, LUNAME=LUDBD1(PASSWORD=....)

You can also determine the location name of DB2 in DDF by one of the following methods:

  1. Stop/Start DDF. When you start DDF, you will see the location name as well as the LU name for DB2.
  2. Check the syslog for a DB2 message DSNL004I (=DDF started ok). The location name will be here as well.

Return to the top

If your database is DB2 for Linux, UNIX, and Windows:

Problem: The database server name specified in the StarSQL data source setup does not match the relational database directory entry for the database.

Solution: Check the database name for your DB2 using the Control Center.

Return to the top

Section number not valid (#144)

Problem: You are using static packages on DB2 that are incompatible with either your new DB2 system or with the new version of your StarSQL driver.

Solution: After upgrading StarSQL or your DB2, you must drop (or delete) the old StarSQL static packages and bind (create) new static packages. Drop or delete the packages manually on the DB2 host. To bind a new set of packages, follow the instructions in the technical document Binding StarSQL Packages Using StarAdmin or How to Bind Packages with StarAdmin Classic.

Return to the top

<authid> does not have the privilege to perform operation execute on <STARSQL>.SWRC0000

Problem: The user attempted to use a StarSQL package that he or she does not have permission to use.

Solution: By default, only the user who bound the package can use it; the DBA or another user with equivalent authority must grant other users permission to use or execute the StarSQL static packages. You can use StarAdmin to grant execute authority to PUBLIC. For more information about the StarSQL packages, see the StarAdmin Help or the StarSQL Help.

Return to the top

bind authorization error using <authid> authority package = <authid>.SWCATPKG privilege = bindadd
bind authorization error using <authid> authority package = <authid>.SWRC0000 privilege = create in
bind authorization error using <authid> authority package = <STARCOLL>.SWRC0000 privilege = create in

Problem: The user does not have permission to bind the StarSQL packages in the collection specified in the Package Collection Name field or the package already exists.

Solution: Check with your DBA to make sure you have CREATEIN and BINDADD authority on the package collection specified in the StarSQL data source. If you already have a static package, drop the package first before creating a new one. For more information about the StarSQL static packages, see the StarAdmin Help and the StarSQL Help.

Return to the top

Unexpected DRDA reply codepoint x`2208`

Problem: The user attempted to bind (or create) a static package in a collection in which he is not permitted to bind packages.

Solution: Obtain the necessary DB2 permissions to bind static packages, or request that the DBA bind these packages for you.In order to bind the StarSQL static packages, the user needs both BINDADD and CREATE IN authority. For more information about the StarSQL static packages, see the StarAdmin Help and the StarSQL Help.

Return to the top

Unexpected DRDA reply codepoint x`1254` (DB2 for i)

Problem: You will get this error if the Database Server Name specified in the StarSQL data source setup does not match the relational database directory entry configured on the IBM i system. You can also get a similar error if you are attempting to bind packages and you do not have sufficient authority on the IBM i system.

Solution: Check the relational database directory entry for the DB2 for I system using the command WRKRDBDIRE. If no entry exists with a location of (*LOCAL), then add one. If you get this error when you are attempting to bind packages, check with your IBM i Administrator ensure that you are able to write to the library specified as the Package Collection Name. For more information, see the StarSQL Help.

 

DRDA Distributed Data Management (DDM) errors

Problem: After updating StarSQL, connecting with an existing ODBC data source fails with the error:

[StarSQL][StarSQL ODBC Driver]Distributed Data Management (DDM) parameter X'1913' not supported.

Solution: This error may occur if the DSN is configured for UseEncryption=No.

On Windows, use ODBC Administrator, select the DSN, and do one of the following:

  • Select the Security/Accounting panel: Enable User ID/Password Encryption and select Encrypt When Supported by Host
  • Select the Advanced panel and change to UseEncryption=Any.

On UNIX, edit $HOME/.odbc.ini or /usr/local/etc/odbc.ini and change UseEncryption=No to UseEncryption=Any.

Problem: connection fails with this error

[StarSQL][StarSQL ODBC Driver] Distributed Data Management (DDM) Stream Syntax Error caused by object(X'11A1')

Solution: The user was using a connection string, but the PkgColId (Package Collection ID) was not specified. Connection successful after adding PkgColId=STARSQL.

Problem: connection fails with this error

[StarSQL][StarSQL ODBC Driver] Distributed Data Management (DDM) parameter value X'2112' not supported (*0)

Solution: The user specified an invalid value (STARSQL 5.63) for PkgColId (Package Collection ID). When this value was changed to a valid value (STARSQL563), connection was successful.

[StarSQL][StarSQL ODBC Driver]Distributed Data Management (DDM) Resource Limits Reached.

Solution: The user specified an incorrect value for the Database Server Name when connecting to a DB2 for LUW system, supplying the hostname or the SPM_NAME (Syncpoint Manager Name) rather than the database name. For example, the database SRV101DB resides on a Windows system named SRV101; and SPM_NAME is set to SRV101. This error was encountered when the user specified SRV101 rather than SRV101DB as the Database Server Name.

Unsupported function for SPMDB connect (DB2 LUW)

Problem: When connecting to DB2 LUW (Linux, UNIX & Windows), you get the following error:

Unsupported function for SPMDB connect Command is not supported. SQLSTATE=58014

Solution: This problem may occur if the SPM_NAME on the DB2 LUW system is set to the same name as the database being connected to. The default value of SPM_NAME (Syncpoint Manager Name) is derived from the TCP⁄IP hostname.

See: the IBM note SQL30070N "Unsupported function for SPMDB connect" Command is not supported. SQLSTATE=58014

Enter the following to confirm the diagnosis:

Windows: db2 get dbm cfg | findstr "SPM_NAME"
UNIX: db2 get dbm cfg | grep "SPM_NAME"

If you are not using the Syncpoint Manager, set SPM_NAME to NULL or to any value other than the database name.

db2 update dbm cfg using SPM_NAME NULL

Return to the top

Failure to load libiconv

Problem: StarSQL fails to connect with the error

[StarSQL][StarSQL ODBC Driver]Library not found, or wrong version found, for libiconv.

This error may occur if the ODBC application, or another ODBC driver used by the ODBC application, loads a different version of libconv-2.dll than the one supplied with StarSQL. Note that if StarSQL is used first by the application, then StarSQL will load successfuly and the second ODBC driver will encounter a similar problem. This situation has been observed with Tableau and with the PostgreSQL psqlODBC v09.05.

Solution: Update to StarSQL 6.31 or later.

FD:OCA descriptor is invalid

Problem: The following error was encountered:

S1000(0)[StarSQL][StarSQL ODBC Driver][Distributed Data Management(DDM) The FD:OCA descriptor is invalid (0,02)

Solution: This error may occur if the application binds a parameter using SQLBindParameter(), specifying a value for ColumnSize, and then exceeds that length when passing actual data.

Also, be aware of the locale of the client system, since that might affect the length of strings. This error was encountered at a customer site where StarSQL was running on Solaris; if the locale in such an environment is something other than UTF-8, there is a greater chance of problems when binding with SQL_C_CHAR.

SYSIBM views and system cross-reference tables (DB2 for i)

If you encounter issues with catalog calls on a DB2 for i system, especially after an OS update, verify that the SYSIBM library is complete by running the command CALL QSYS/QSQIBMCHK to invoke the SYSIBM object verification tool.

If any objects are missing, run the command CALL QSYS/QSQSYSIBM to create any objects missing from the SYSIBM library.

In addition , the catalog cross-reference tables can become corrupted during operations such as a failed release upgrade or a sudden power failure (no UPS).

To verify the state of the cross-reference information for all libraries, specify RCLDBXREF *CHECK.

To attempt to correct the cross-reference information for a specific library without taking the system to a restricted state, use the RCLDBXREF *FIX MYLIB command where MYLIB represents the specific library to correct.

To rebuild all the system-cross reference files, run RCLSTG *DBXREF from a restricted state. On large systems, the RCLSTG operation can take long periods of time. It is recommended that this operation be done only if necessary.

see Verifying System Catalog Information for ODBC Use for details.

Issues with AES password encryption requirement

Problem: Connection to a DB2 for i system fails with the error:

[StarSQL][DB2] A local security server retryable error has occurred

Solution: This error may occur if the minimum encryption level of the DDM server has been set to *AES rather than the default of *DES, and StarSQL is configured for useEncryption=ANY (default). To examine the current value, enter the command CHGDDMTCPA and hit F4.

Either set the minimum encryption level of the DDM server to *DES:

CHGDDMTCPA AUTOSTART(*YES) PWDRQD(*USRIDPWD) ENCALG(*DES)

or change the StarSQL ODBC data source to use useEncryption=No, using either the Advanced panel or the Security/Accounting panel. This assumes that the PWDRQD parameter is not configured to require encryption; if the PWDRQD parameter is configured to require encryption, use useEncryption=No and connect via SSL; the host will ignore the password encryption requirement if the entire conversation is encrypted in SSL

Similarly, StarSQL for Java can be configured with the property pwdEncryption; possible values are True or False.

DB2 for z/OS may be configured for AES encryption by setting the TCPALVER (TCP/IP ALREADY VERIFIED) subsystem parameter of installation panel DSNTIP5 to SERVER_ENCRYPT and Installing and configuring z/OS Integrated Cryptographic Services Facility (ICSF). The resulting error message may look different. Like the DB2 for i host, set useEncryption=No and connect via SSL

A similar issue may occur if DB2 for LUW is configured to require AES encryption using the DBM parameters authentication=Server_encrypt and alternate_auth_enc=AES_ONLY, resulting in the error:

Attempt to establish connection failed with security reason <17> (<UNSUPPORTED FUNCTION>)

There is no workaround for DB2 for LUW configured to require AES encryption.

Installation: Error 1260 - software restriction policy

Problem: The following error was observed when updating StarSQL on a system running Windows Server 2003 after installing Windows updates issued between October 2014 and August 2015:

Error 1260: Windows cannot open this program because it has been prevented by a software restriction policy.

Solution: Remove StarSQL from the Add/Remove Control Panel and reinstall it. The problem is not encountered when doing a fresh installation.

Password Length Limitation

Currently StarSQL supports passwords up to 15 characters; using a longer password may cause the application to crash. This issue will be resolved in a future version of StarSQL.

 


DISCLAIMER

The information in technical documents comes without any warranty or applicability for a specific purpose. The author(s) or distributor(s) will not accept responsibility for any damage incurred directly or indirectly through use of the information contained in these documents. The instructions may need to be modified to be appropriate for the hardware and software that has been installed and configured within a particular organization.  The information in technical documents should be considered only as an example and may include information from various sources, including IBM, Microsoft, and other organizations.