Issue 75444 - JDBC fails to retrieve all metadata or data
Summary: JDBC fails to retrieve all metadata or data
Status: CLOSED DUPLICATE of issue 74732
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: OOo 2.2 RC3
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: dbaneedsconfirm
QA Contact: issues@dba
Depends on:
Reported: 2007-03-16 09:09 UTC by ianst
Modified: 2013-08-07 15:45 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description ianst 2007-03-16 09:09:18 UTC
Please refer to previous issue 15113 originally resolved to a large degree by
Frank Schonheit.

Currently, using the IBM UniVerse JDBC driver one can define a connection to an
existing database and successfully test and connect to the datasource.  A Test
Class and Test Connection are both successful.

Using the Tables function a list of tables is retrieved and displayed in the
Tables pane.  When clicking on Tables,  OOo,  via the JDBC driver, issues an SQL
 SELECT to the UniVerse DBM to retrieve the schema data etc and a list of tables
is displayed.  However when opening a table OOo complete crashes - ie OOo closes
down after a few seconds including quickstart, soffice.bin and soffice.exe.

On restart, OOo recovers but does not generate a log file even crashrep.exe is 
manually started.

In previous versions of OOo which worked reasonably well with the UniVerse JDBC
apart from some minor issues (see issue 49043), it was necessary to run a macro
to set certain values in the .odb file.  Running this macro does not seem to
make a difference.

Ian Stuart
Comment 1 Frank Schönheit 2007-04-02 12:22:02 UTC
To me, this sounds like a (technical) duplicate of issue 74732, even if the
descriptions don't really match.

Ian, if I would provide you with a modified library (not for production use),
would you be able to check whether it solves the problem in your installation? I
would build the lib based on the final 2.2 release, for Windows or Linux (your
Comment 2 ianst 2007-04-02 16:13:07 UTC
Hi Frank,
Yes certainly/please I'll be very glad to try the modified library.  Both
Windows and Linux are important platforms for us but we are trying to get away
from MSQuery and other MS tools to query UniVerse databases.  Can we try a
Windows implementation first.

Ian Stuart
Comment 3 Frank Schönheit 2007-04-02 19:54:23 UTC
okay, please try the "i74732.fix.ooo22.<platform>" files from
They contain a library which should be the 2.2 version plus a fix for 74732.
Comment 4 ianst 2007-04-04 10:56:46 UTC
i74732.fix.ooo22 seems to have have fixed quite a few issues I was having.  I
have yet to try the Linux patch but will do so asap.

There are other issues which vary depending on advanced database settings which
I will document as soon as I understand what is happnening.

Many thanks for your support.

Comment 5 Frank Schönheit 2007-04-04 11:31:20 UTC
That's great. If those issues are already submitted, I would like to set them as
duplicate to issue 74732, since this helps me arguing why 74732 must get a
target 2.2.1 (instead of 2.3).
Am I right in assuming that issue 75444 (this one here) and issue 75442 belong
to the fixed ones?
Comment 6 ianst 2007-04-04 13:46:26 UTC
Hi Frank,

No, it seems that 75442 is still a problem, ie ODBC connections to the same
datasources as accessed via JDBC fail although the symtoms are now different.

However all is not lost as there is definitely an improvement over previous OOo
versions and testing I've done with UniVerse.

As background - UniVerse supports 2 types of SQL "schemas" 1. a "true" SQL
schema with Catalog defintions, triggers, constraints, views etc which are
enforced by the DBMS and 2. a "free-form" "ACCOUNT" which enables the user to
create non-SQL tables/files,  and implement rules in client applications only
(although triggers are also supported).  (A third option also exists in that
non-SQL tables can be created in SQL Schemas - used for speed eg hashed tables).
 However non-SQL files are "sqlised" on the fly by the ODBC driver as long as
the dictionaries of these files have been massaged to make the data ODBC
compliant and the Account is marked as accessible via ODBC.

The symptoms are different when connecting to a SQL schema vs Universe ACCOUNT
as follows:

Connecting to "true" SQL Schema:

I can connect to the data source but no tables are shown.  Trying to select
Query facilities, eg Create Query in SQL View does not enable me to access the
database or create queries.  This is unusual as, for example, "true" UniVerse
SQL Schemas are more easily accessed via ODBC applications than UniVerse
Accounts as the Schema and catalog take care of everything, ie there is no
manual intervention required to make non-SQL tables accessible via ODBC.  I have
also tested that the username has been GRANTed the correct priveleges.

Also, I do get the same error message as reported in 75442 when OOo crashes.

Connecting to an UniVerse Account:

The behaviour changes slightly here: While OOo does not retrieve/display the
table definitions as for SQL Schemas,  I am able to create a query in Create
Query in SQL View and retrieve data from the table - however trying to then
enter design view results in a message stating that the "CUSTOMER_MASTER" is not
a table or a query.  I have tried disabling schema and catalog names in Advanced
Settings but that makes no difference.

In an Account I can also access the facilities to create tables and the correct
data types for columns is shown, which is not the case with the JDBC,  although
UniVerse disallows actual creation of the tables as SQL DML is not permitted in
UniVerse accounts.

In both cases (Schemas and Accounts) if I check on the server a connection has
been made and a call to obtain the schema details is made.

FYI I am testing against the latest IBM UniVerse database version 10.2 with
associated JDBC and ODBC drivers.

I'm not sure if I should put the above on issue 75442 ?

Ian Stuart
Comment 7 Frank Schönheit 2007-04-04 14:54:40 UTC
> I'm not sure if I should put the above on issue 75442 ?

Yes, please do. I would like to close this one here as duplicate of issue 74732,
since it seems to have the same internal reason (and since this would raise the
chances I'm allowed to fix issue 74732 in 2.2.1 instead of 2.3).

> FYI I am testing against the latest IBM UniVerse database version 10.2
> with associated JDBC and ODBC drivers.

Sigh. I don't have a Universe installation anymore (perhaps I should have
installed it in some virtual machine, so it would have survived), and given my
previous experiences, I currently am not too eager to embark on this
time-consuming installation odyssee, again ... :-\
Comment 8 Frank Schönheit 2007-04-04 22:19:18 UTC
okay, I see you added your comments to issue 75442 - thanks.

Closing this one as duplicate of issue 74732, since the fix is the same.

*** This issue has been marked as a duplicate of 74732 ***
Comment 9 Frank Schönheit 2007-04-04 22:20:29 UTC
closing duplicate