At 01:20 AM 5/04/2007, you wrote:

>Hi! I'm getting an overflow error for the MYDATE variable in this
>instruction:
>
> INSERT INTO TEMP (CLIENTID,MYDATE,FLAG) VALUES (:MYCLIENT,:MYDATE,1);
>
>
> the debugger shows that it tries to insert doing this:
> INSERT INTO TEMP (CLIENTID,MYDATE,FLAG) VALUES (1,CAST
> ('01/13/2007' AS DATE),1);
> but the debugger also shows MYDATE variable as 13/01/2007, why
> does it reverse the day and the month to insert?
> MYDATE type is DATE
> I'm in IB 7.5

Don't you have the manuals that came with IB 7.5? You need to study
the Data Definition Guide.

Your parameterised statement:

INSERT INTO TEMP (CLIENTID,MYDATE,FLAG)
VALUES (:MYCLIENT,:MYDATE,1)

requires parameters of the correct type to be passed to it from your
application. Your application should pass a data structure that the
API recognises as a date. A string is not a date. So, for example,
if your application is in Delphi, it should pass a TDate and your
BeforeInsert event would need to pick that up from a variable somewhere, e.g.

var
MyDate: TDate;
..
begin
..
MyDate := MyDateTimePicker.Date;
MyStatement.ParamByName('MYDATE').AsDate := MyDate;
...
end

You can also pass dates and times as string literals (although you
can't pass string literals to DATE parameters). You really can't
hope to guess the formats of the string literals so, some day real
soon, you are going to need to read the documentation.

For example, the string literal format 'xx/xx/xxxx' is *always*
'mm/dd/yyyy'. The string literal format 'xx.xx.xxxx' is always
'dd.mm.yyyy'. (These are just the most common examples: there are
many other recognised string literal formats). Your debugger is
trying to guess what you really want and it's getting it wrong by
some strange warp of logic.

You could have submitted a request containing a valid date literal,
as follows, and it would have worked just fine:

INSERT INTO TEMP (CLIENTID,MYDATE,FLAG)
VALUES (99, '13.1.2007',1)

./heLen