DB2 date format issue

[Dario Di Bella]

Hi all,
we have the following urgent issue affecting our development team.
Initially we had one particular workstation that failed executing
queries on a DB2 database, raising an invalid date format exception
(SQLSTATE=22007). The same queries worked fine on all the other
workstations. The date format we want to use is "dd/mm/yyyy".After
reinstalling several times the db2 runtime client w/ different
options, we found on a technical forum the following instructions that
seemed to solve our problem:

db2 bind @d2ubind.lst datetime ISO
db2 bind @d2cli.lst datetime ISO

We tried to launch the commands from the non-working workstation, but
as a result now the malfunction (i.e. SQLSTATE=22007) now affects also
all the other workstations.
What can be happened?
Is there a sort of "roll back" on those commands, so that the
preceding configuration can be restored?
Any help will be greatly appreciated.
Thanks.

[Mark A]

"Dario Di Bella" <da************@libero.it> wrote in message
news:63**************************@posting.google.c om...

Hi all,
we have the following urgent issue affecting our development team.
Initially we had one particular workstation that failed executing
queries on a DB2 database, raising an invalid date format exception
(SQLSTATE=22007). The same queries worked fine on all the other
workstations. The date format we want to use is "dd/mm/yyyy".After
reinstalling several times the db2 runtime client w/ different
options, we found on a technical forum the following instructions that
seemed to solve our problem:

db2 bind @d2ubind.lst datetime ISO
db2 bind @d2cli.lst datetime ISO

We tried to launch the commands from the non-working workstation, but
as a result now the malfunction (i.e. SQLSTATE=22007) now affects also
all the other workstations.
What can be happened?
Is there a sort of "roll back" on those commands, so that the
preceding configuration can be restored?
Any help will be greatly appreciated.
Thanks.

Without looking at the manual to verify this, I would try:
db2 bind @d2ubind.lst datetime USA
db2 bind @d2cli.lst datetime USA

[Rhino]

"Dario Di Bella" <da************@libero.it> wrote in message
news:63**************************@posting.google.c om...

Hi all,
we have the following urgent issue affecting our development team.
Initially we had one particular workstation that failed executing
queries on a DB2 database, raising an invalid date format exception
(SQLSTATE=22007). The same queries worked fine on all the other
workstations. The date format we want to use is "dd/mm/yyyy".After
reinstalling several times the db2 runtime client w/ different
options, we found on a technical forum the following instructions that
seemed to solve our problem:

db2 bind @d2ubind.lst datetime ISO
db2 bind @d2cli.lst datetime ISO

We tried to launch the commands from the non-working workstation, but
as a result now the malfunction (i.e. SQLSTATE=22007) now affects also
all the other workstations.
What can be happened?
Is there a sort of "roll back" on those commands, so that the
preceding configuration can be restored?
Any help will be greatly appreciated.

The format you specified, 'dd/mm/yyyy', is *not* ISO format. ISO format is
'yyyy-mm-dd'. In fact, your format, 'dd/mm/yyyy' is not one of the
"standard" formats (ISO, JIS, EUR) at all, although it is *similar* to the
EUR format ('dd.mm.yyyy'). If you want to use a non-standard format like
'dd/mm/yyyy', I believe you need to use DATETIME LOC or DATETIME DEF in the
bind commands that you issued, not DATETIME ISO. However, if you want to use
DATETIME LOC or DATETIME DEF, I believe you have to write your own datetime
exit program and plug it into DB2. This program would have two jobs:
1. store any incoming date, which would be in 'dd/mm/yyyy' format, in
yyyymmdd format, which is the internal format used for all DB2 dates.
2. reformat any stored date, which would be in yyyymmdd format, and return
it in 'dd/mm/yyyy' format.

In the past, these exit programs had to be written in Assembler (at least on
the mainframe) but I'm not sure if this is the case for DB2 on
Windows/Unix/Linux. Unfortunately, I haven't been able to find information
about the coding of these exits in the manuals. With any luck you could
simply write a user-defined function in a higher level language like Java or
C to do this for you.

If you really want to go to that effort, feel free. You might find it easier
to use the standard EUR format, 'dd.mm.yyyy', in which case you would
probably end your errors by doing the two BIND commands again, this time
with DATETIME EUR. That should get your programs and queries working again
immediately and give you time to decide if you want to change over to
DATETIME LOC later.

IMPORTANT: I should warn you that the advice I've just given you may not
work and may even make your situation worse. It seems possible that there is
a codepage issue here but I'm not very experienced with codepage problems. I
have no experience at all with the interactions of date exit programs with
code pages, assuming you decide to write such a program. Therefore, what I'm
advising *could* make things worse. I strongly advise you to research this
issue carefully before acting if you want to be absolutely sure that you
don't make the problem worse.

Rhino

[Dario Di Bella]

Rhino,
thanks for your advice, but something is still unclear.
In the original situation all the workstations worked properly using
the 'dd/mm/yyyy' date format. Only one workstation failed, reporting
the date format exception. Hence what can we desume about the datetime
settings in the original situation? Is there a way to restore such
settings?
An IBM support site states about the datetime setting:

'[...]If not specified, it defaults based on the country/region code.'

I think that this should be the original setting, and the failure of a
single workstation can be explained as a result of bad country/region
settings on that specific client.
Is that possible? If so, how can I 'unset' the datetime code?

Thanks.

dario.

The format you specified, 'dd/mm/yyyy', is *not* ISO format. ISO format is
'yyyy-mm-dd'. In fact, your format, 'dd/mm/yyyy' is not one of the
"standard" formats (ISO, JIS, EUR) at all, although it is *similar* to the
EUR format ('dd.mm.yyyy'). If you want to use a non-standard format like
'dd/mm/yyyy', I believe you need to use DATETIME LOC or DATETIME DEF in the
bind commands that you issued, not DATETIME ISO. However, if you want to use
DATETIME LOC or DATETIME DEF, I believe you have to write your own datetime
exit program and plug it into DB2. This program would have two jobs:
1. store any incoming date, which would be in 'dd/mm/yyyy' format, in
yyyymmdd format, which is the internal format used for all DB2 dates.
2. reformat any stored date, which would be in yyyymmdd format, and return
it in 'dd/mm/yyyy' format.

In the past, these exit programs had to be written in Assembler (at least on
the mainframe) but I'm not sure if this is the case for DB2 on
Windows/Unix/Linux. Unfortunately, I haven't been able to find information
about the coding of these exits in the manuals. With any luck you could
simply write a user-defined function in a higher level language like Java or
C to do this for you.

If you really want to go to that effort, feel free. You might find it easier
to use the standard EUR format, 'dd.mm.yyyy', in which case you would
probably end your errors by doing the two BIND commands again, this time
with DATETIME EUR. That should get your programs and queries working again
immediately and give you time to decide if you want to change over to
DATETIME LOC later.

IMPORTANT: I should warn you that the advice I've just given you may not
work and may even make your situation worse. It seems possible that there is
a codepage issue here but I'm not very experienced with codepage problems. I
have no experience at all with the interactions of date exit programs with
code pages, assuming you decide to write such a program. Therefore, what I'm
advising *could* make things worse. I strongly advise you to research this
issue carefully before acting if you want to be absolutely sure that you
don't make the problem worse.

Rhino

[Dario Di Bella]

Mark,

I guess that USA datetime format is 'mm/dd/yyyy', while our desired
format is 'dd/mm/yyyy'. Correct?

Thanks.

Dario.

[Rhino]

Dario,

You raise an excellent question. The truth is, I don't know why your other
workstations were working at one point. I don't know enough about your
configurations and settings to be able to explain it to you. In fact, you
haven't even said which version of DB2 you are using or what platform you
have. I assumed you were using DB2 V7 or V8 for Windows/Unix/Linux - and
should have said so in my post. Perhaps if you can tell us your DB2 version
and platform, we can figure out exactly why your workstations were behaving
differently. Perhaps the workstation that failed was using a different
codepage or language setting than the others.

As far as I know, there is no way to "rollback" the commands that set the
DATETIME format; you have to change the desired datetime format via the bind
commands that you used, at least in DB2 V7 for Windows/Unix/Linux. If you
are on DB2 for z/OS or AS/400, or have an earlier or later version of DB2,
the solution may be different.

We really need to know which version of DB2 you are using, which platform
you are using, and which DB2 product (Workgroup Edition, EE? EEE?) you are
using first to be sure that we are looking in the right manuals to solve
your problem.

I suggested rebinding with DATETIME EUR because you said your situation was
urgent. It could solve your problem quickly, except that there are some
risks. It is safer to diagnose your problem more thoroughly but it will take
a little longer....

Rhino

"Dario Di Bella" <da************@libero.it> wrote in message
news:63**************************@posting.google.c om...

Rhino,
thanks for your advice, but something is still unclear.
In the original situation all the workstations worked properly using
the 'dd/mm/yyyy' date format. Only one workstation failed, reporting
the date format exception. Hence what can we desume about the datetime
settings in the original situation? Is there a way to restore such
settings?
An IBM support site states about the datetime setting:

'[...]If not specified, it defaults based on the country/region code.'

I think that this should be the original setting, and the failure of a
single workstation can be explained as a result of bad country/region
settings on that specific client.
Is that possible? If so, how can I 'unset' the datetime code?

Thanks.

dario.

The format you specified, 'dd/mm/yyyy', is *not* ISO format. ISO format is 'yyyy-mm-dd'. In fact, your format, 'dd/mm/yyyy' is not one of the
"standard" formats (ISO, JIS, EUR) at all, although it is *similar* to the EUR format ('dd.mm.yyyy'). If you want to use a non-standard format like
'dd/mm/yyyy', I believe you need to use DATETIME LOC or DATETIME DEF in the bind commands that you issued, not DATETIME ISO. However, if you want to use DATETIME LOC or DATETIME DEF, I believe you have to write your own datetime exit program and plug it into DB2. This program would have two jobs:
1. store any incoming date, which would be in 'dd/mm/yyyy' format, in
yyyymmdd format, which is the internal format used for all DB2 dates.
2. reformat any stored date, which would be in yyyymmdd format, and return it in 'dd/mm/yyyy' format.

In the past, these exit programs had to be written in Assembler (at least on the mainframe) but I'm not sure if this is the case for DB2 on
Windows/Unix/Linux. Unfortunately, I haven't been able to find information about the coding of these exits in the manuals. With any luck you could
simply write a user-defined function in a higher level language like Java or C to do this for you.

If you really want to go to that effort, feel free. You might find it easier to use the standard EUR format, 'dd.mm.yyyy', in which case you would
probably end your errors by doing the two BIND commands again, this time
with DATETIME EUR. That should get your programs and queries working again immediately and give you time to decide if you want to change over to
DATETIME LOC later.

IMPORTANT: I should warn you that the advice I've just given you may not
work and may even make your situation worse. It seems possible that there is a codepage issue here but I'm not very experienced with codepage problems. I have no experience at all with the interactions of date exit programs with code pages, assuming you decide to write such a program. Therefore, what I'm advising *could* make things worse. I strongly advise you to research this issue carefully before acting if you want to be absolutely sure that you
don't make the problem worse.

Rhino

[Rhino]

Dario,

As a followup to my previous posts, I've done some further research and
found an article on how to set up a custom date format so that you can have
'dd/mm/yyyy', instead of 'dd.mm.yyyy'.

CAUTION: The article is written for DB2 for Windows/Unix/Linux so the
techniques may not be applicable is you are using DB2 on a different
platform! If you are using a different platform, I will try to find similar
information for your platform.

Here is the URL:
http://www-106.ibm.com/developerwork.../0211yip3.html

As you will see, the article contains information on how to change the date
format and how to write a custom date/time UDF so that you can have a format
like 'dd/mm/yyyy'. Of course, you will not be able to use the UDF shown in
the example *exactly* as shown; you will have to modify it for your format.
But the example is a good basis for your own program. All you have to do is
modify this example for your format, then install it just like you would any
other UDF. This shouldn't take more than an hour or two if you have some
developers familiar with writing UDFs.

However, this isn't the ideal solution yet: the best solution would be for
all dates to display as 'dd/mm/yyyy' *without* having to convert them via a
UDF. I will do more research to see how that can be done. This is an
interesting problem and I'm curious to know the answer myself.

Rhino