Bug 40144

May be useful:

 system: Debian GNU/Linux
 architecture: amd64
 g++ (Debian 4.6.1-4) 4.6.1
 libstdc++6     4.6.1-4

Reproduced with:
 LibreOffice 3.3.3
 OOO330m19 (Build:301)
 tag libreoffice-3.3.3.1, Debian package 1:3.3.3-4+b1
Still on amd64

This one was compiled with
 g++ 4:4.6.0-6
 lbstdc++6 4.6.1-1

The python scripting does *not* have this problem with LO 3.3 (Debian package as above), still on amd64, on the same computer, so same run-time libstdc++ and all that.

Test script:

import uno
from com.sun.star.util import Date


def getThisDataBaseDocument():
    doc = XSCRIPTCONTEXT.getDocument()
    while not 'com.sun.star.sdb.OfficeDatabaseDocument' in doc.SupportedServiceNames:
        doc = doc.Parent
    return doc


def tst_setDate(e):
    ctx = uno.getComponentContext()
    smgr = ctx.ServiceManager
    IntrcHndl = smgr.createInstanceWithContext( "com.sun.star.task.InteractionHandler",ctx)
    db = getThisDataBaseDocument()
    conn = db.DataSource.connectWithCompletion(IntrcHndl)
    stmt = conn.prepareStatement("SELECT * FROM tblName WHERE colName > ? LIMIT 1")
    stmt.setString(1, "1/1/2005")
    stmt.setInt(1, 18)
    stmt.setDate(1, Date(1, 1, 2005))
    rs = stmt.executeQuery()
    while rs.next():
        print "Col1:", rs.getString(1)

Reproduced this with
 OO.org 3.2.1
 OOO320m18 (Build:9502)
on Microsoft Windows.

So the problem is most probably not in architecture/OS-specific bridge code, but in the general Basic<->Uno glue code. Now, what makes "setDate" special, I don't know. My first hunch was another setDate from another interface, but grepping through the code does not find a likely candidate.

(In reply to comment #4)

Hi Lionel,

> 
> So the problem is most probably not in architecture/OS-specific bridge code,
> but in the general Basic<->Uno glue code. Now, what makes "setDate" special, I
> don't know. My first hunch was another setDate from another interface, but
> grepping through the code does not find a likely candidate.


I remember reading a reply (in a bug report I think) from Frank Schoenheit (former OOo dba longtime dev also from StarOffice times) where he recognised that there are places in the UNO/CPP code where there are possibly mismatches between functions, or even functions that were included in the CPP, but had no corresponding or conflicting calls in UNO. This might be one of them.


Alex

Hmmm,

Trawling around in old stuff brings this up as a known problem, at least in the context of usage of setDate() in prepared statements, see this post from 2009 :

http://www.oooforum.org/forum/viewtopic.phtml?t=86978


Alex

Is this of any use ?

http://www.mail-archive.com/dba-bugs@openoffice.org/msg35418.html


Alex

(In reply to comment #7)

> Is this of any use ?

> http://www.mail-archive.com/dba-bugs@openoffice.org/msg35418.html

Yes, indeed. If one passes a proper "com.sun.star.util.Date" structure as second argument of setDate(), then it works.

As I understand your link (and generally http://openoffice.org/bugzilla/show_bug.cgi?id=113436), LOBasic/UNO calls the setDate method for a ::com::sun::star::awt::XDateField because the type signature happens to match (a Basic "Date" type is convertible to a long integer). I would consider that a bug; the object "stmt" in my example code does not implement the XDateField interface, so there is no good reason to even consider XDateField's setDate method.

@Lionel
do your comments 2,3 say that the problem appeared for you between LibO 3.3.0 and LibO 3.3.3? Or what was the first version for what yo observed the problem?

(In reply to comment #9)
> @Lionel
> do your comments 2,3 say that the problem appeared for you between LibO 3.3.0
> and LibO 3.3.3? Or what was the first version for what yo observed the problem?

First version I observed the problem; according to references given in other comments the "problem" is actually much older than that, as it no a straight bug, rather more a very unnatural interface, coupled with no or bad typechecking, leading to non-useful error messages.

The situation is that XStatement::setDate expects a com.sun.star.util.Date UNO structure. However, it seems "natural" from a BASIC programmer's point of view that DateSerial(year, month, day) will return the right thing, or it will be automatically converted or some such, since it is the "canonical" way to construct a date in BASIC.

Compare with:

 stmt.setInt(1, "142")

which will correctly call XStatement::setInt(1, 142): the string is automatically parsed and converted to an integer.

The error message is not very informative, and is actually wrong: it says "Object variable not set": which variable? Which object? The first thought is of the "stmt" variable, so one does not understand the error message, as the stmt variable _is_ set. It is the only variable in that statement, so from the user's POV, it can only be about this variable.

A much better error message would be "XInterface::setDate argument 2: com.sun.star.util.Date expected, but integer provided".

Some lesser, but still OK alternatives:
 - Could not initialise com.sun.star.util.Date from integer
 - Could not initialise com.sun.star.util.Date
 - com.sun.star.util.Date expected

The least good, but still better than the present would be "Object value not set": value instead of variable. Slightly better "Object of type com.sun.star.Date not set".

[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html

AFAIK, situation has not changed in LibO 3.5 or even LibO 3.6

Adding self to CC if not already on