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

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

Adding self to CC if not already on

Dear Lionel Elie Mamane,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug