This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes JDBC and the fly likes java.sql.SQLException:Loss of significance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Databases » JDBC
Bookmark "java.sql.SQLException:Loss of significance" Watch "java.sql.SQLException:Loss of significance" New topic
Author

java.sql.SQLException:Loss of significance

Neena Mehta
Greenhorn

Joined: Dec 19, 2008
Posts: 5
Hi,

I am getting this exception "java.sql.SQLException: DB001001 T1340 C-4M322: Loss of significance" when trying to insert a record from java to idms database through jdbc.
I don't get this problem every time I insert a record, I get the error occasionally like, let's say I insert 3 to 4 records straight, it inserts successfully all the records and wait for few minutes like 2-3 minutes and try inserting then I get the above error message.
I feel like its getting timed out, but know idea where to look into.
Everytime I insert a record I am opening the connection to idms, writing the record and closing the connection.
I am using Tomcat 5.0.28, idmsjdbc.jar to connect to idms.

The error:
java.sql.SQLException: DB001001 T1340 C-4M322: Loss of significance
at ca.idms.jdbc.IdmsJdbcObject.getSQLException(IdmsJdbcObject.java)
at ca.idms.jdbc.IdmsStatement.getSQLException(IdmsStatement.java)
at ca.idms.jdbc.IdmsJdbcObject.getSQLException(IdmsJdbcObject.java)
at ca.idms.jdbc.IdmsPreparedStatement.execUpdate(IdmsPreparedStatement.java)
at ca.idms.jdbc.IdmsPreparedStatement.executeUpdate(IdmsPreparedStatement.java)
at insertIDMSRecord(insertIDMSRecord.java:788)

That 788 line is:
int i = preparedStament.executeUpdate();

I am not sure if I really explained the problem that well but if you need any info. I'll be glad to help.


I am really struggling with this problem for few days.
Any help is greatly appreciated.


Thank You.
Paul Campbell
Ranch Hand

Joined: Oct 06, 2007
Posts: 338
are you doing some type of calculation in your insert? Loss of signifcance is a floating point calculation type of error.
Neena Mehta
Greenhorn

Joined: Dec 19, 2008
Posts: 5
Originally posted by Paul Campbell:
are you doing some type of calculation in your insert? Loss of signifcance is a floating point calculation type of error.


I am not doing any calculation but converting from int to string and to int, like this:
Calendar c = new GregorianCalendar();
c.setTime(admitDate);
int omDay = c.get(Calendar.DATE);
int omMonth = c.get(Calendar.MONTH) + 1;
int year = c.get(Calendar.YEAR);
String stryear = year + "";
String strOmCen = stryear.substring(0, 2);
int omCen = Integer.parseInt(strOmCen);
String strOmYear = stryear.substring(2);
int omYear = Integer.parseInt(strOmYear);

Do you think this might cause anything like that?

By the way this is the jdbc driver I am using to connect to idms.
ca.idms.jdbc.IdmsJdbcDriver


Thank you for replying me back. I really appreciate.
Paul Campbell
Ranch Hand

Joined: Oct 06, 2007
Posts: 338
I don't know a lot of about IDMS... but is your date stored as a number or a date?

I do notice in your code (if I assume your date is > Dec 31, 1999) the value for omYear would no longer have a leading zero (2008's year would be "08") represented in strOmYear and would now be a single digit "8" (i.e., 2008 would now be "8")... perhaps that is what is causing your exception since the database is either looking for for a 2 digit year or for a leading zero where you're representing year.
Neena Mehta
Greenhorn

Joined: Dec 19, 2008
Posts: 5
Originally posted by Paul Campbell:
I don't know a lot of about IDMS... but is your date stored as a number or a date?

I do notice in your code (if I assume your date is > Dec 31, 1999) the value for omYear would no longer have a leading zero (2008's year would be "08") represented in strOmYear and would now be a single digit "8" (i.e., 2008 would now be "8")... perhaps that is what is causing your exception since the database is either looking for for a 2 digit year or for a leading zero where you're representing year.


Date is stored as a number in IDMS.
Even I had the same doubt before and I tried to insert through IDMS Command Prompt with year giving 8 instead of 08, it did insert successfully. And that too the problem is, I could insert few records through java code successfully but sometimes I get that error.
If at all there is a problem with the java code it should not work for the first time too according to my thinking, I might be wrong too.

I also confirmed from one of our Mainframe developer about the 2 digit year. He said if we supply 2-digit that's fine and even if we give one digit, it takes as it is a number.

Do you think it might be problem with the connection to IDMS?

I really really appreciate as you are showing some interest to find out the problem. I haven't seen anybody responding.
Since this is my first time posting to a forum and seeing someone replying, I really feel very happy.

Thank you again.
Paul Campbell
Ranch Hand

Joined: Oct 06, 2007
Posts: 338
I am really just guessing here... but here goes... dates on all (that I am aware of) RDBMS databases are stored as numbers... but those numbers are defined as being a date column... is that true about this column? I'm asking since often times a mainframe programmer (and also SQL developers have a perverse enjoyment about not giving you all the facts by answering literally... i.e., is the date stored as a number... literally yes... but it is defined as a date).

Have you tried identifying the offending rows (print the row that errors) and seeing if you can insert that same row in SQL? Have you tried pulling rows off the table to see if they look similar to your inserted rows or if there are differences in format? The error message isn't very helpful and you may need to wrap your date in a SQL TO_DATE function... but if you put on your data analyst hat and start by identifying the differences between a sample of the problem rows, the rows that work (do those rows insert 100% of the time?), and some already in the table you will be a long ways towards finding your answer.
Neena Mehta
Greenhorn

Joined: Dec 19, 2008
Posts: 5
Originally posted by Paul Campbell:
I am really just guessing here... but here goes... dates on all (that I am aware of) RDBMS databases are stored as numbers... but those numbers are defined as being a date column... is that true about this column? I'm asking since often times a mainframe programmer (and also SQL developers have a perverse enjoyment about not giving you all the facts by answering literally... i.e., is the date stored as a number... literally yes... but it is defined as a date).

Have you tried identifying the offending rows (print the row that errors) and seeing if you can insert that same row in SQL? Have you tried pulling rows off the table to see if they look similar to your inserted rows or if there are differences in format? The error message isn't very helpful and you may need to wrap your date in a SQL TO_DATE function... but if you put on your data analyst hat and start by identifying the differences between a sample of the problem rows, the rows that work (do those rows insert 100% of the time?), and some already in the table you will be a long ways towards finding your answer.



In IDMS, everything is either a number or string. There is nothing like a date type. I have checked the data type for the 'year' field in IDMS and it is declared as number.
The only option I have like you said, is to comment out that field and try inserting the records. If I still get the prolem, then I know that its not because of that field.

Anyway thank you for your interest. If at all you come up with something please do write.

Thanks.
Neena Mehta
Greenhorn

Joined: Dec 19, 2008
Posts: 5
Hi,

I wanted to let you know that my problem is solved.
There was a timestamp filed in IDMS which was causing problem.
Our DBA posted the problem to IDMS Bulletin board where one of the CA Group
looked into it and said There is a bug in the IDMS interface that occasionally causes a "Loss of Significance" error on the truncation of the low order digits. CA has a test APAR to fix the problem.

I wanted to share with you guys, if at all you come up with similar problem you know that it is a bug in the IDMS Interface.


Thanks.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: java.sql.SQLException:Loss of significance
 
Similar Threads
java.sql.SQLException: [Micorsoft][ODBC Microsoft Access Driver] Too few parameters.
How to insert a file in oracle blob object
java.sql.SQLException: ORA-00942
reading and writing large data(200000) from oracle
Help: Connecting Tomcat to CA-IDMS Using JDBC Type 4 Drivers (JNDI / IDMSDataSource)