On Fri, Sep 02, 2011 at 06:26:40PM +0200, Alexander Thurgood wrote:
Le 02/09/11 18:05, Lionel Elie Mamane a écrit :
So, I wanted to check whether it is policy that SDBC drivers must
accept ODBC escapes in SQL strings, or whether there would be
interest in me gradually changing LibreOffice to *not* use
ODBC-specific escapes.
How would you envisage the prepared statement working with the
filter functionality currently available in forms, for example,
where this transition from date literal is transparent for the user
(because the query is generated on the fly) ?
Exactly: it is transparent for the user, because the query is
generated on the fly; in the example of a table, instead of the "on
the fly" query being generated as e.g. (con being the connection):
stmt = con.createStatement();
rs = stmt.executeQuery("SELECT * FROM tblName WHERE dtColumn = {D 2011-08-28}");
something like that would be done (where filterDate is the
::com::sun::star::util::Date containing the date to filter on):
stmt = con.prepareStatement("SELECT * FROM tblName WHERE dtColumn = ?");
stmt.setDate(1, filterDate);
rs = stmt.executeQuery();
On Fri, Sep 02, 2011 at 06:33:10PM +0200, Alexander Thurgood wrote:
Might this also have an impact on Basic macros, which currently have
to convert Basic com.sun.star.util.Date used as a date variable into
something that the XParameter setDate can understand because the two
are not the same ?
No, that won't have an effect on the fact that Basic macros using the
prepared statement interface have to convert the Basic date type
(basically an integer, if I remember well) into a
com.sun.star.util.Date structure.
--
Lionel
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.