Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 594
  • Last Modified:

java.sql.date problem

I use  j2ee 1.3.1  with  jdk1.4.1 on a Solaris SPARC and have the following problem:

From any application client from a field type java.sql.date hardly I make  update  date '2003-03-20' it store in the data base as '2003-03-19'.


Which problem exists, it is bug?


Thanks



George Liolios
0
gla
Asked:
gla
  • 14
  • 6
  • 5
  • +5
1 Solution
 
Mayank SAssociate Director - Product EngineeringCommented:
I am sorry but I don't understand your question very well. I guess that if you wnat to store 2003-03-20, then it is storing 2003-03-19, right?

Mayank.
0
 
glaAuthor Commented:
Exactly,

When user write in text field 2003-03-20 and press the update button, then it is stored 2003-03-19.

I think the problem is combined between client and j2ee server.



I tryied to prin
0
 
Mayank SAssociate Director - Product EngineeringCommented:
Is it happening with all the dates?? I mean, try the extremes like:

2003-05-31
2003-02-28

Also, try 2003-02-29 and 2003-05-32 and see what it writes.

Mayank.
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
girionisCommented:
 I do not think it is a bug but you can always check the bug database here: http://java.sun.com/j2se/1.4/fixedbugs/index.html

  I'd say it's a database problem. Can you check the configurations/manuals of your database and see if you can find anything weird?
0
 
glottisCommented:
try storing the date with # around them like this: #2003-03-20#
0
 
andrybinyaCommented:
Maybe it's a problem of Time Zone settings of Database server?
0
 
girionisCommented:
> Maybe it's a problem of Time Zone settings of Database server?

  It shouldn't though since the database is supposed to store whatever receives from the client. Even if the time zone is different on the database server the value it receives from the client should not conflict with the server.
0
 
allahabadCommented:
Check , if you have ON UPDATE trigger on that table, that decrease a day from the requested value of the date, while updating date column in that table..
0
 
objectsCommented:
Whats the type in the database, and how are you storing and retrieving it.
0
 
glaAuthor Commented:
I use an Oracle 8i Second Edition on a Linux Intel Rehat Server.

I User Container Managed Persisted EJB 's to STORE and Retrieve Data.

For your help if I use the J2EE 1.3 and not J2EE 1.3.1 then
all is fine
0
 
glaAuthor Commented:
I use an Oracle 8i Second Edition on a Linux Intel Rehat Server.

I User Container Managed Persisted EJB 's to STORE and Retrieve Data.

For your help if I use the J2EE 1.3 and not J2EE 1.3.1 then
all is fine
0
 
girionisCommented:
 Why don't you stick with J2EE 1.3 then?
0
 
glaAuthor Commented:
>Is it happening with all the dates?? I mean, try the >extremes like:

>2003-05-31
>2003-02-28

>Also, try 2003-02-29 and 2003-05-32 and see what it writes.

>Mayank.

I tried 2003-05-32 and I retrieve 2003-05-31
also 2003-02-29 and I retrieve 2003-02-28


George
0
 
glaAuthor Commented:
>Is it happening with all the dates?? I mean, try the >extremes like:

>2003-05-31
>2003-02-28

>Also, try 2003-02-29 and 2003-05-32 and see what it writes.

>Mayank.

I tried 2003-05-32 and I retrieve 2003-05-31
also 2003-02-29 and I retrieve 2003-02-28


George
0
 
Mayank SAssociate Director - Product EngineeringCommented:
>> I tried 2003-05-32 and I retrieve 2003-05-31

Then probably the only thing you can do is increment the day by one and then insert the date for every transaction :-)

Mayank.
0
 
Mayank SAssociate Director - Product EngineeringCommented:
Something makes me feel that this is a Locale problem..

Mayank.
0
 
Mayank SAssociate Director - Product EngineeringCommented:
Are your sure that your time-zone settings at the client and server sides match?

Mayank.
0
 
glaAuthor Commented:
Yes I am sure the time-zone match.

George

0
 
Mayank SAssociate Director - Product EngineeringCommented:
Then I think its just that the server is taking the date to be one day before the actual date. Guess its a very hard-to-debug problem unless we actually get to see it!

Mayank.
0
 
glaAuthor Commented:
Yes I am sure the time-zone match.

George

0
 
glaAuthor Commented:
Mayank

I remind you that with the j2ee1.3 working fine!


George.
0
 
girionisCommented:
 It shouldn't be a time-zone problem since the db server inserts the value it receives from client (whatever this value is).

  gla whta's the issue of using 1.3 instead of 1.3.1?
0
 
glaAuthor Commented:
Mayank

I remind you that with the j2ee1.3 working fine!


George.
0
 
glaAuthor Commented:
The reasons of using j2ee 1.3.1 is
Performance improvement running enterprise beans and
I use Sun One studio update 1 that working with j2ee 1.3.1

George
0
 
glottisCommented:
1.
can u insert the date to the database manually. see how the db reacts to that.

2.
create another simple application and use a JTextField and write the proper date in that field then .getText() and insert that in the db and see.

3.
if possible use other application (in java) to  insert dates.

4.
if possible use other application (not in java) to  insert dates.

5.
when inserting other value (other than dates) are the results ok ?

6.
when you do enter the date, and server stores wrong data, dont do any thing simply commit and then retrieve that data is it showing it right or not ?
0
 
objectsCommented:
And you still haven't told us what the database type of the date in the database is.
0
 
glaAuthor Commented:
The database (Ora8i) field type is date.

If i insert a row in database manually everthing is fine.

After many test with j2ee and jdk on solaris sparc.


I see that:

a. compine j2ee1.3.1 and jdk1.4.1 on solaris sparc:

dates
17/10/1950
17/10/1960
17/10/1970
17/10/1980
17/10/1990
17/10/2000

stored fine.

dates
17/10/1974

stored 16/10/1974

a. compine j2ee1.3.1 and jdk1.3_02 on linux redhat 7.0:

all dates working fine!

Please note that the database server is on defered machine than application server (j2ee)!

 
George Liolios


0
 
glaAuthor Commented:
The database (Ora8i) field type is date.

If i insert a row in database manually everthing is fine.

After many test with j2ee and jdk on solaris sparc.


I see that:

a. compine j2ee1.3.1 and jdk1.4.1 on solaris sparc:

dates
17/10/1950
17/10/1960
17/10/1970
17/10/1980
17/10/1990
17/10/2000

stored fine.

dates
17/10/1974

stored 16/10/1974

a. compine j2ee1.3.1 and jdk1.3_02 on linux redhat 7.0:

all dates working fine!

Please note that the database server is on defered machine than application server (j2ee)!

 
George Liolios


0
 
glaAuthor Commented:
The database (Ora8i) field type is date.

If i insert a row in database manually everthing is fine.

After many test with j2ee and jdk on solaris sparc.


I see that:

a. compine j2ee1.3.1 and jdk1.4.1 on solaris sparc:

dates
17/10/1950
17/10/1960
17/10/1970
17/10/1980
17/10/1990
17/10/2000

stored fine.

dates
17/10/1974

stored 16/10/1974

a. compine j2ee1.3.1 and jdk1.3_02 on linux redhat 7.0:

all dates working fine!

Please note that the database server is on defered machine than application server (j2ee)!

 
George Liolios


0
 
glaAuthor Commented:
The database (Ora8i) field type is date.

If i insert a row in database manually everthing is fine.

After many test with j2ee and jdk on solaris sparc.


I see that:

a. compine j2ee1.3.1 and jdk1.4.1 on solaris sparc:

dates
17/10/1950
17/10/1960
17/10/1970
17/10/1980
17/10/1990
17/10/2000

stored fine.

dates
17/10/1974

stored 16/10/1974

a. compine j2ee1.3.1 and jdk1.3_02 on linux redhat 7.0:

all dates working fine!

Please note that the database server is on defered machine than application server (j2ee)!

 
George Liolios


0
 
girionisCommented:
 I'd say there is probably some bug with the J2EE or JDK implementation on this specific functionallity. Maybe you could check the bugbase for similar problems or report it (http://developer.java.sun.com/). My only suggestion would be to stick with the versions that work or, if you stick with the versions that do not work, subtract one from the date every time you do a submission.
0
 
CleanupPingCommented:
gla:
This old question needs to be finalized -- accept an answer, split points, or get a refund.  For information on your options, please click here-> http:/help/closing.jsp#1 
EXPERTS:
Post your closing recommendations!  No comment means you don't care.
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 14
  • 6
  • 5
  • +5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now