At 02:54 PM 14-02-01 +1300, you wrote:

>IB ss 6 / IBO 3.6 Ca / D4
>
>I use the data format string ddddd which reflects users choice of any
>given short date format.
>In the on prepare event of a stored procedure, query or cursor I provide
>
>SQLWhereItems as date and others.
>
>Only dmy, mdy, ymd works for stored procedures, and worse only mdy, ymd
>works for queries and cursors. That's no good. The user should be able
>to pick any format they want!

Sure! but you will have to intercept the input in order to get it into the format that InterBase wants for storage or for parameter inputs to stored procedures, viz.

mm/dd/yy or mm/dd/yyyy
dd.mm.yy or dd.mm.yyyy
dd-MMM-yy or dd-MMM-yyyy

IB 6 onwards, add
yyyymmdd (ISO date format)

Have you tried using IBO's MaskEdit to have IBO do the hard work of intercepting and converting? I'm not sure, but I seem to remember MaskEdit will only convert the masked entries to mm/dd/yyyy format...

>This looks to me as though there is some filtering being done here
>implying restrictions as to what date format the user can select unless
>the application performs an expensive date format analysis to provide in
>
>turn the restricted date format for queries.
>
>What's wrong here?
>Who is it?
>Interbase or IBO?

It's InterBase (or any full-blown SQL RDBMS, for that matter). Date types are not stored as strings, as they are in some of the desktop databases, they are stored in a numeric format. You have to pass them in SQL as date literals, that is, an acceptable date format string in single quotes OR as one of the the predefined date literals ('NOW', 'TODAY', 'YESTERDAY', 'TOMORROW') OR (in IB6 only) as the system variables CURRENT_DATE, CURRENT_TIMESTAMP or CURRENT_TIME.


All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________