Issue 63448 - Cannot edit anything in Sybase SLQAnywhere tables via JDBC
Summary: Cannot edit anything in Sybase SLQAnywhere tables via JDBC
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: OOo 2.0.2
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: needmoreinfo
Depends on:
Reported: 2006-03-22 00:03 UTC by valence
Modified: 2013-02-07 22:41 UTC (History)
3 users (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 valence 2006-03-22 00:03:48 UTC
Using Sybase SQLAnywhere Ver 8.0.2.  jdbc driver is also used with Sybase
Adaptive Server Enterprise.

Running queries, browsing tables all works fine.

However, editing just doesn't work!  I can select a field to edit, change to
edit cursor, but it just doesn't accept any keystrokes.

Table has a primary key and OO can see it. Privileges are fine.

Are there any diagnostic facilities to figure out why it doesn't want to edit?
Comment 1 christoph.lukasiak 2006-04-24 10:39:22 UTC
have you the possibility to try an other driver (maybe odbc) ?
Comment 2 christoph.lukasiak 2006-04-24 15:41:26 UTC
set keyword 'needmoreinfo'
Comment 3 valence 2006-04-27 09:14:31 UTC
Yes it seems to work fine in ODBC, so it's a JDBC specific thing. I have been
using Sybase's jdbc drivers for a very long time now (i.e. not the same version
but with many versions) and it's a pretty good implementation.

So I guess we have a workaround, but I would really like the jdbc support to
work as well.
Comment 4 christoph.lukasiak 2006-05-15 15:55:41 UTC
change owner
Comment 5 christoph.lukasiak 2006-05-15 15:59:42 UTC
editing works fine with mysql jdbc in m168 => no general editing problem with oo
over jdbc
Comment 6 christoph.lukasiak 2006-05-15 16:07:42 UTC
clu->valence: sorry, but oo cannot fit to every driver/driverchange if the
driver ignore jdbc standards - in this case we have no jdbc problem, but a
specific driver problem - maybe you find a 'better' driver for your needs

p.s. for jdbc diagnostic programs (there exist several) please ask the experts
in the correspronding newsgroups/mailinglist (also for alternative drivers).
Comment 7 valence 2006-05-16 02:06:20 UTC
valence->clu: The sybase driver is definitely the driver to use...would not
consider using any alternative. We have used this driver extensively in our own
jdbc applications and have not found any problems ourselves. I would be very
surprised if the driver was in some way non-compliant.

I suspect it's probably more to do with some type of meta-data behaviour that is
not fully covered by the jdbc standard, but which OO is relying on.

Can you point me to what definitive criteria OO is using to decide that the
table is non-editable? [I don't want to have go scrounging through the source code!]

I would not expect OO to have to cut to every vendor's proprietary extensions,
but this should not be the issue with this one.

I will followup on the jdbc diags.
Comment 8 christoph.lukasiak 2006-05-16 10:19:03 UTC
reopen for comment
Comment 9 christoph.lukasiak 2006-05-16 10:27:18 UTC
clu->valence: sorry for closing this issue - after rethinking i will investigate
that further (and yes, it seems that the inconsistence is in the metadata area)

p.s. thank you for your patience
Comment 10 christoph.lukasiak 2006-05-17 11:54:10 UTC
i can repro the described behavior -> no editing of tables possible with
jconn3.jar jdbc-driver (jconnect6.05)
Comment 11 christoph.lukasiak 2006-05-17 11:56:11 UTC
complete summary
Comment 12 christoph.lukasiak 2006-05-17 12:03:06 UTC
clu->oj: may you have a deeper look at that

p.s. primary key is shown in table design - values are shown in insert mode, but
no edit of content is possible
Comment 13 marc.neumann 2006-08-03 10:08:36 UTC
msc -> oj:
the same is in a JDBC Derby db. The driver doesn't return valid TablePrivileges,
however I have turn on the "IgnoreDriverPrivileges" option is the options.

Comment 14 valence 2006-08-08 02:55:50 UTC
I just tested the very latest release of jconn3.jar.

No change in behavior. It still doesn't allow edits.

If you think this problem is being caused by jdbc metadata coming back from the
driver is incorrect in some way please let us know and we can raise a problem on
Comment 15 ocke.janssen 2006-08-08 09:50:14 UTC
As far as I can imagine this is a problem of the ResultSetMetaData. If
isReadOnly(column) returns true, the field is switched to read-only mode. You
may try the "RespectDriverResultSetType" setting at the datasource. Here you'll
find the macro to execute

-- OJ
Comment 16 valence 2006-08-08 10:02:28 UTC
I can't imagine that this is the there any way to view the metadata
that OO has got for the table columns?
Comment 17 ocke.janssen 2006-08-08 10:29:38 UTC
You could use
to test the driver. Just register the driver connect to your database and set
the resultsettype to SCROLL_SENSITIVE and the ResultSetConcurrency to UPDATABLE
and prepare a statement like "select * from table1" and execute it. Afterwards
check the resultsetmetadata if  column 1 isReadOnly(1).

-- OJ
Comment 18 valence 2006-08-08 11:02:34 UTC
Ah yes...I have got to the bottom of this.

The sybase column metadata does indeed return readOnly true when it should not.

I then checked the jconnect programmer documentation, and this method, along
with a few others, is not supported. 

So the question is, are these methods "optional" from the point of view of the
jdbc api?

And then how do we tell Openoffice to ignore the readOnly column metadata.

Comment 19 ocke.janssen 2006-08-08 12:02:24 UTC
There exists two ways:
1. Sybase could fix this issue. Which would be the best way from my side.
2. We introduce a new option for this. This would take some time because it is
such a special item (IgnoreReadOnlyResultSetMetaData) option. Sorry. May be it
will be faster when more people vote for this issue.

Could you submit this issue to Sybase? ;-)

Best regards,


PS: I assign the issue at issues@dba because it's a driver bug.

Comment 20 ocke.janssen 2006-08-08 12:03:17 UTC
Comment 21 valence 2006-08-08 12:20:42 UTC
Well I can try opening a bug with Sybase, but I doubt they'll do anything in a

Comment 22 Frank Schönheit 2006-08-08 14:26:44 UTC
fs->valence: Would be interesting to have a reasoning for isReadOnly returning
|true|. That is, I can understand that fully implementing this might be
expensive, and thus omitted. However, in such a case it would make much more
sense to be defensive, and return |false| instead. |true| breaks every
application which tries to respect the JDBC API ...
Comment 23 valence 2006-08-08 14:39:18 UTC
Yes that was my thinking too, and that is the gist of the bug I have created on
Sybase. If they aren't going to implement it, I have suggested it should return

In the past I have found them to be pretty responsive to bug reports, and
regularly come out with updates, so it will be interesting to see what happens.

The Sybase case # is 11275952
Comment 24 avbidder 2008-04-02 14:15:40 UTC
Rather crude hack because Sybase is lame and doesn't fix this issue...

--- connectivity/source/drivers/jdbc/ResultSetMetaData.cxx.orig
+++ connectivity/source/drivers/jdbc/ResultSetMetaData.cxx
@@ -502,7 +502,7 @@
        jboolean out(sal_False);
        SDBThreadAttach t;
-       if( t.pEnv ){
+/*     if( t.pEnv ){
                // temporaere Variable initialisieren
                static const char * cSignature = "(I)Z";
                static const char * cMethodName = "isReadOnly";
@@ -515,7 +515,7 @@
                        ThrowLoggedSQLException( m_aLogger, t.pEnv, *this );
                        // und aufraeumen
                } //mID
-       } //t.pEnv
+       } //t.pEnv                                          */
        return out;
 // -------------------------------------------------------------------------
Comment 25 Frank Schönheit 2008-04-02 14:31:18 UTC
Ah, somebody knowing how to code C++!

Interested in getting guidance in how to fix this properly? I.e., how to
implement the option Ocke talked about? This would be a per-database option,
which is forwarded to and respected by our JDBC driver, and tells it to ignore
the ReadOnly-ness. You could then set this option for your databases in question ...
Comment 26 avbidder 2008-04-02 14:40:22 UTC
> Ah, somebody knowing how to code C++!

Commenting out stuff in a very obvious function is hardly "knowing to code 
C++" ... :-)

> Interested in getting guidance in how to fix this properly? I.e., how to
> implement the option Ocke talked about?

Interested?  Yes.  Possibility?  Close to Zero.  Sorry - I'm not interested 
enough to do this in my spare time, and $CUSTOMER won't pay me for this as 
long as this 10-minute (compile time not included) hack continues to work.  
Should any of this change I'll call back, though.
Comment 27 Martin Hollmichel 2008-06-06 15:02:53 UTC
move target to 3.x
Comment 28 Frank Schönheit 2010-12-01 12:09:11 UTC
"owner issues@dba" means: it's to be fixed OOo-externally, which contradicts the
"3.x" target. resetting target.