Hello,
Did you connect with the connect
> option 'unicode=yes'?
Thanks, i've missed it!
-------------------------------------------
> what invalid timestamp value was delivered to you, and is
> that error reproducable?
Java:
callSelect = conn.prepareCall("{call DBA.SELECT_DATA}");
...
rs.getObject(j+1); /* the message translation buffer value was: '2003-10-01
00:00:00.00000 + CHR(-15)' */
Environment is similar to:
CREATE TABLE TableName
(
"ID" Integer DEFAULT SERIAL (1),
"STRING_COL" Varchar (80) UNICODE NOT NULL,
"SMALLINT_COL" Smallint NOT NULL DEFAULT 1,
"BOOLEAN_COL" Boolean DEFAULT TRUE,
"TIMESTAMP_COL" Timestamp,
PRIMARY KEY ("ID")
)
//
CREATE TABLE AnotherTable
(
"ID_N" Integer DEFAULT SERIAL (1),
"ID" Integer NOT NULL,
"STRING_COL" Varchar (8) UNICODE NOT NULL,
"STRING2_COL" Varchar (60) UNICODE NOT NULL,
"BOOLEAN_COL" Boolean DEFAULT TRUE,
"TIMESTAMP_COL" Timestamp,
PRIMARY KEY ("ID_N"),
FOREIGN KEY FK_AnotherTable ("ID") REFERENCES TableName ("ID")
)
//
CREATE DBPROC SELECT_PRE_ZONE RETURNS CURSOR AS
TRY
$CURSOR = 'SELECT_RESULT';
DECLARE :$CURSOR CURSOR FOR
SELECT Z.ID,Z.SMALLINT_COL,N.STRING_COL,N.TIMESTAMP_COL
FROM DBA.TableName Z, DBA.AnotherTable N;
CATCH STOP ($RC, 'SELECT_DATA:' & $ERRMSG);
values from SP invocation:
1 1 01 2003-12-10 00:00:00.000000
2 2 02 2003-12-10 00:00:00.000000
Pranas
----- Original Message -----
From: "Schroeder, Alexander" <[EMAIL PROTECTED]>
To: "'Pranas'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, December 10, 2003 10:04 AM
Subject: RE: JDBC
> Hello Pranas,
>
> what invalid timestamp value was delivered to you, and is
> that error reproducable? Did you connect with the connect
> option 'unicode=yes'? This seems to be a kernel problem,
> so looking a a vtrace (http://sapdb.2scale.net/moin.cgi/VTrace)
> would be possibly a good idea to check where the invalid time
> stamp had its source.
>
> And no, we don't want to remove significant numbers from
> the timestamp, as they are normally there and should not be
> broken or garbled.
>
> And no, we will not mess around with java.text.SimpleDateFormat
> as its 'elegance' is at the price of awkward performance overhead
> for the simple cases (and we have only one timestamp format here, no
> custom ones), and it has funny differences on different JDK
> versions.
>
> I may think of an additional check of the source to see if it
> has only digits at those significant places, and throwing an
> SQLException if the value is definitely garbage.
>
> Regards
>
> Alexander Schr�der
> SAP DB, SAP Labs Berlin
>
> > -----Original Message-----
> > From: Pranas [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, December 10, 2003 10:30 AM
> > To: [EMAIL PROTECTED]
> > Subject: JDBC
> >
> >
> > Hello JDBC gurus,
> >
> > SAP DB JDBC driver should be fixed:
> >
> > Invalid calculation of nanoseconds in
> > com.sap.dbtech.jdbc.translators.TimestampTranslator.getTimesta
> > mp line 143:
> > int nano= (milli*10 +((int)raw[23]-'0'))*100;
> > should be replaced to:
> > int nano= ((int)raw[23]-'0')*100;
> >
> > For SAP DB 7.4.3.30 UNICODE instance timestamp value is
> > passed incorrectly
> > via network. raw[25] is corrupted and used in
> > com.sap.dbtech.jdbc.translators.TimestampTranslator.getTimesta
> > mp line 145!
> > Quick workaround: remove access to the raw[25].
> >
> > Are there plans to remove deprecated Java API calls? Java
> > standard time
> > conversion function may be possibly more efficient ?... e.g. by using
> > java.text.SimpleDateFormat code would look more elegant.
> >
> > Regards,
> > Pranas
> >
> >
> > --
> > MaxDB Discussion Mailing List
> > For list archives: http://lists.mysql.com/maxdb
> > To unsubscribe:
> > http://lists.mysql.com/[EMAIL PROTECTED]
> >
>
> --
> MaxDB Discussion Mailing List
> For list archives: http://lists.mysql.com/maxdb
> To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
>
>
>
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
