Issue 63448

have you the possibility to try an other driver (maybe odbc) ?

set keyword 'needmoreinfo'

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.

change owner

editing works fine with mysql jdbc in m168 => no general editing problem with oo
over jdbc

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).

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.

reopen for comment

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

i can repro the described behavior -> no editing of tables possible with
jconn3.jar jdbc-driver (jconnect6.05)

complete summary

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

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.

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
Sybase.

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
http://www.mail-archive.com/dba-bugs@openoffice.org/msg07809.html

-- OJ

I can't imagine that this is the reason..is there any way to view the metadata
that OO has got for the table columns?

You could use
http://java.sun.com/developer/onlineTraining/Database/JDBCShortCourse/jdbc/exercises/JDBCTestConnect/index.html
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

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.

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,

Ocke

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

.

Well I can try opening a bug with Sybase, but I doubt they'll do anything in a
hurry.

Thanks...
Milt

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 ...

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
false. 

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

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;
 }
 // -------------------------------------------------------------------------

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 ...

> 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.

move target to 3.x

"owner issues@dba" means: it's to be fixed OOo-externally, which contradicts the
"3.x" target. resetting target.