OpenOffice and Rdb ODBC

Question

I have the Oracle Rdb Driver v3.0.2 installed on a Windows client and a User DSN connection established in the ODBC Data Source Administrator control panel applet. I can query successfully with clients like MSQuery, Excel (with the SQLREQUEST() array function), and my terminal emulator (SmarTerm 9) which comes with built-in SQL functions. However, with OpenOffice 1.0 and 1.0.1, which comes with a query builder similar to MSQuery, I cannot get a proper list of available tables once the connection is made to the remote database.
There are 3 log files on the client which offer some clues, but it is not clear (to me) whether the Oracle driver is faulty, or it's OpenOffice that's the problem. Buried in two of the logs are SELECT statements which appear to pass invalid SQL syntax to the database, causing it to return no table names.
The first log is generated by the ODBC Data Source Administrator itself when Tracing is enabled. It's name is SQL.LOG by default. The other two logs are CLIENT.LOG and RDBODBC.LOG, generated by SQL/Services and the driver, respectively. The first, SQL.LOG, contains the following lines at the point where OpenOffice is requesting the list of tables:
scalc fff01057-fff017d7     ENTER SQLTablesW
          HSTMT 0314028C
          WCHAR * 0x00000000
          SWORD 0
          WCHAR * 0x00000000
          SWORD 0
          WCHAR * 0x0323FFE8 [      -3] "%"
          SWORD -3
          WCHAR * 0x0314067C [      -3] "VIEW,TA"
          SWORD -3
scalc fff01057-fff017d7     EXIT SQLTablesW with return code 0 (SQL_SUCCESS)
          HSTMT 0314028C
          WCHAR * 0x00000000
          SWORD 0
          WCHAR * 0x00000000
          SWORD 0
          WCHAR * 0x0323FFE8 [      -3] "%"
          SWORD -3
          WCHAR * 0x0314067C [      -3] "VIEW,TA"
          SWORD -3
The second log, produced by SQL/Services on the client, shows that the '%' wildcard has been changed to '% '. Here's the SQLTablesW call in that log:
ROUTINE LEVEL LOG at 11:19:43 on 07-Sep-2002
----SQLSRV_PREPARE
--------SQL STATEMENT
------------len: 233, value: SELECT '',rdb$flags,rdb$relation_name,rdb$system_fl
------------ag,'' FROM rdb$relations WHERE rdb$system_flag=0 AND rdb$relation_na
------------me LIKE '% ' ESCAPE '&' ORDER BY rdb$sy
------------stem_flag DESC,rdb$flags ASC,rdb$relation_name
PROTOCOL LEVEL LOG CLIENT: write (logonly) at 11:19:43 on 07-Sep-2002
----PACKET LENGTH: 245
PROTOCOL LEVEL LOG CLIENT: write (logonly) at 11:19:43 on 07-Sep-2002
----PACKET ID: 3, PACKET SEQUENCE: 0
--------SQLSRV_PREPARE
------------SQL STATEMENT
----------------SQLSRV_COUNTED_BYTES, len: 233
--------------------len: 233, value: SELECT '',rdb$flags,rdb$relation_name,rdb$s
--------------------ystem_flag,'' FROM rdb$relations WHERE rdb$system_flag=0 AND
-------------------- rdb$relation_name LIKE '% ' ES
--------------------CAPE '&' ORDER BY rdb$system_flag DESC,rdb$flags ASC,rdb$rel
--------------------ation_name
--------END OF MESSAGE
Finally, the RDBODBC.LOG driver log shows a similar change to the LIKE clause of the SELECT statement:
.0X00700138: SELECT '',rdb$flags,rdb$relation_name,rdb$system_flag,'' F
.ROM rdb$relations WHERE rdb$system_flag=0 AND rdb$relation_name LIKE '
.% ' ESCAPE '&' ORDER BY rdb$system_flag D
.ESC,rdb$flags ASC,rdb$relation_name
I'm no ODBC developer, but perhaps someone can suggest why the spaces are being added?
Thanks,
Alder

Answer 1

Unfortunately RDB and Oracle are two completely different animals, so I'm really out of my element.
My wild, uninformed, shot-in-the-dark guess is that this has something to do with Unicode. When Unicode data is encoded as UCS-2 (Windows default encoding), ASCII characters are stored in two bytes, [ACSII value][00]. The ODBC Driver Manager is supposed to know whether a driver supports Unicode and to translate Unicode data passed through it to ASCII if that's what the driver needs. Perhaps the translation isn't happening properly here...
If you look at the SQL.log file for the applications that work, I'm going to guess that you see the function SQLTablesA (ASCII version) being called, rather than SQLTablesW.
Justin