
APAR= II09468
CA400WINOPT CLIENT ACCESS ODBC DRIVER (32-BIT)

                                      Last updated 12/11/96  DXD


COMMON PROBLEMS WITH THE 32 BIT ODBC DRIVER
___________________________________________

Problem:
 "I can't connect with the ODBC driver"

Resolution:
 See II09599 ODBC Troubleshooting: Section 1
 Unable to Connect to the AS/400; Section 3.1
 Connection Errors.
 Things to Check on the AS/400 System:
   Communication Link Failure COMM RC=0XC
   Communication Link Failure COMM RC=0X3

           -------------------

Problem:
 "Once I connect to the AS/400 I can't see any libraries."

Resolution:
 Set your default library list to include the libraries
 you want. (Client Access ODBC Setup, Server page,
 Default libraries option)

           -------------------

Problem:
 "When I open a table, it appears to be empty even though
 there is data in it."

Workaround:
 It is likely that your application is trying to open the
 table for update but it can't, so it just displays an
 empty grid. Look at the Client Access Online User Guide
 under "Troubleshooting ODBC Problems" section
 "ODBC - Enabling tables to be updated".

           -------------------

Problem:
   Can I use the Client Access ODBC driver with my 16 bit
   applications?

Answer:
   Yes.  To connect a 16 bit application to the as/400 via
   ODBC requires a thunk layer to convert the 16 bit
   ODBC api calls to 32 bit api calls.  We currently
   offer two methods to accomplish this.  The method
   you must use depends on how your PC is connected to
   the AS/400.

   IF YOU ARE CONNECTED VIA TCP/IP OR IPX:
   You can use the ODBC thunk dll included with
   the ODBC driver.  Simply configure a 32 bit
   ODBC driver source for the AS/400 and add
   the client access shared directory to the path
   statement of your autoexec.bat file.
   If you installed Client Access into the default
   directory the path would be:
   C: PROGRA 1 IBM CLIENT 1 SHARED where the blank
   should be a tilde.

   IF YOU ARE CONNECTED VIA SNA (NETSOFT, SNA SERVER,
   NOVELL SAA, or other OEM WINAPPC router):
   Please see II09863 for detailed instructions.

         --------------------

Problem:
 16 bit applications do not list the 32 bit data sources.

Resolution:
1) ONLY IF YOU ARE TCP/IP or IPX CONNECTED

 TCP and IPX connected users should be using the
 16 to 32 bit thunk which is part of ODBC 2.5.
 See the II09863 for details.

 Verify that the Client Access shared directory is
 in your path.  Open a DOS box and type PATH.  You
 should see Client Access shared directory listed.
 The default path used by the installation program
 is C: PROGRA 1 IBM CLIENT 1 SHARED where the blank
 should be a tilde.

 If you still encounter problems, check the version
 of the ODBC.DLL file in the windows system
 directory.  If it is older then version 2.10,
 then another application has down leveled the
 driver.  Replace it. This error is often seen
 when installing 16 bit versions of Microsoft
 Access or Office after Client Access for
 windows 95 was installed.

  Other causes of the error:
  -  The application you are using bypasses the
     ODBC driver manager and directly loads the
     ODBC dll.  This will also bypass the thunk.
     This type of application will not work with
     this type of thunk.
  -  The application builds a list of available
     data sources by bypassing the driver manager
     and directly reading the ODBC.INI.
     This type of application may not "see" the 32bit
     data sources.  See the application section
     below, under COGNOS for a possible circumvention.

   2)  SNA CONNECTED USERS
   You must use the 16 bit ODBC driver.  The
   16 to 32 ODBC thunk dll will not work.  See II09863 for
   details.

       --------------------------

Problem:
   Unable to connect using a 16 bit application.

Resolution:
 1) TCP and IPX CONNECTED USERS
    See the sections above:
    "Unable to connect with the ODBC driver"
    "16 bit applications do not list the 32 bit
     data sources".

 2) SNA (802.2 or MSDLC) attached users
    You must be using the 16 bit ODBC driver to
    provide the thunk.  See the II09863 for details.
    If you still encounter problems, verify that:
    - The application vendor supports
      running this application under Windows 95.
    - You have reviewed the instructions in II09863.
    - The shared directory and 16 bit
      client access directories are in your path statement.
    - Client Access has been enabled for "16-bit
      Client Access support"

KNOWN PROBLEMS WITH ODBC-ENABLED APPLICATIONS
_____________________________________________

Microsoft Query version 2.0
---------------------------
Problem:
 The query builder in Microsoft Query generates column
 name length errors when building a query on an AS/400
 table.  MSGSQL0107 is returned by the AS/400.

Cause:
 Query is incorrectly quoting the table name when
 it builds a select statement.  This error
 is returned:  "SQL0107 - "Tablename.Columnname" too long.
 Maximum 10 characters".  Microsoft Query generated
 incorrect ODBC syntax for the statement.

 Details:
 Microsoft Query is not handling delmitied identifiers
 correctly.  Both ANSI SQL and ODBC define support
 for delimited identifiers.  By definition, a
 delimited identifier is case sensitive
 (where ordinary identifiers are converted to uppercase).
 Our ODBC driver supports delimited identifiers and
 reports this by responding to SQLGetInfo with the following
 information:
  SQL_IDENTIFIER_CASE: SQL_IC_SENSITIVE
  SQL_IDENTIFIER_QUOTE_CHAR:  "
  Microsoft Query is incorrectly using this information.
  If you wish to verify this for yourself take
  a SQL log of the failure.
  MS Query generates queries similar to this:
  select FILE.FIELD1, FILE.FIELD2 FROM
  "SYSTEM.LIBRARY".FILE FILE
  This is invalid SQL syntax as "SYSTEM.LIBRARY"
  must be treated as one delimited identifier (in this case
  the owner) rather then qualifier qualifier-separator
  owner-name.table-identifier.
  Some correct examples:
  "SYSTEM"."LIBRARY".TABLE       (SYSTEM.LIBRARY.TABLE)
  SYSTEM.LIBRARY.TABLE           (SYSTEM.LIBRARY.TABLE)
  system.library.table           (SYSTEM.LIBRARY.TABLE)
  "SYSTEM"."LIBRARY"."lctable"    (SYSTEM.LIBRARY.lctable)
   ** Note that "lctable" is interpreted as a case sensitive
      lower case name because of the delimiter.

Workaround:
 We are not aware of a fix from Microsoft so we have
 added a special circumvention with Service Pack SF34548
 for V3R1M0 and Service Pack SF35403 for V3R1M1.
 Our ODBC driver will now detect that it has been loaded
 by MSQRY32.EXE.  When this condition is detected, we
 will disable support for delimited identifiers.
 This will allow MS Query to run against most AS/400
 tables, however you will NOT be able to run against
 SQL tables created with case sensitive names.

Microsoft Excel version 7.0
---------------------------
Problem:
 See the section for Microsoft Query version 2.0 above.
 Excel uses Query to get external data, so the same
 problem applies.


Microsoft Access version 7.0
----------------------------
Problem:
 When the "Sort by" feature of Access is used on an AS/400
 table, it sometimes reports this error:
   SQL0208 - ORDER BY column 'column_name' not in result
   table.

Cause:
 The Microsoft Jet Database Engine will use the ODBC
 cursor library to implement the select.  The SQL
 statement will actually be modified by MS Access (JET)
 to first retrieve all records for the unique keys.  This
 is the statement that will contain the invalid syntax.
 Access generates an invalid SQL statement where it is
 trying to SELECT one column and order by another column
 which is not selected. This is not valid ISO SQL-92 syntax.
 Use the SQL log utility in the ODBC administrator if
 you would like to see the incorrect SQL statement.

Workaround:
 Access requires that you order by a keyed field.


Lotus Approach96
----------------
Problem:
 When an attempt is made to open a file of type "Client
 Access ODBC driver (32-bit)", the following error is
 returned:
   Couldn't find database "systemname library.table"

Cause:
 Approach makes the ODBC connection without using a
 configured data source.  Attempts to access any
 libraries displayed with this method will fail.

Resolution:
 When opening a file, select files of type "ODBC Data
 Sources". Then select the desired Client Access data
 source and proceed from there. The names are handled
 correctly through this method.   DO NOT SELECT "AS/400
 Client Access ODBC"!

Microsoft Visual Basic version 3.0 (16-bit)
-------------------------------------------
Problem:
 When VB 3.0 terminates after having made a Client Access
 ODBC connection, any further attempt by a 16-bit
 application to make a Client Access ODBC connection
 causes an access violation.

Cause:
 When the Visual Basic process ends, it fails to unload
 the 16-bit Microsoft ODBC Driver Manager from memory.
 Memory is thus corrupted and the 16-bit Driver Manager
 cannot be used again.

Workaround:
 Reboot the workstation.

           ----------------------------

Application:
   16 bit Cognos IMPROMPTU
Problem:
   Unable to view ODBC data sources.
Circumvention:
   The following is provided on an "as is" basis.
   See the section above on 16 bit applications unable
   to view 32 bit data sources for more information.

   As of the last update to this document, we have
   not received a formal response from Cognos support.
   It appears that Impromptu is directly reading the
   ODBC.INI file.  They are not listing any data source
   registered under the "ODBC 32 bit Data Sources"
   section.  A circumvention to the problem seems to
   be to copy the 32bit data source for client access
   from the "ODBC 32 bit Data Sources" section to the
   "ODBC Data Sources" section.  Note that in the ini
   file the double quotes appear as square brackets.
   We have not thoroughly tested this circumvention
   to determine if there might be other side-effects.

