Hi. Below is a simple JDBC program to insert and extract
a numerical value. When ResultSet.getDouble() is called,
the same program produces different output on solaris
than it does on Linux. I would be grateful for any
discussion of this!
thanks,
Joe Weinstein at BEA Systems
Results on Linux Box
-----------------------------------------------------------------------
-bash-2.05b$ java db2
08.02.0001
Database version is 08.02.0000
Testing value 1.001
native driver object is a class java.math.BigDecimal
value is 1.001
as getDouble it's 1.0010000000000001 <<<<<<<<<< SEE THIS!
native driver object is a class java.math.BigDecimal
value is 1.001
as getDouble it's 1.0010000000000001 <<<<<<<<<< SEE THIS!
double d = 1.001d gives 1.001
new Double("1.001").doubleValue() gives 1.001
they are equal.
new BigDecimal(1.001d) gives 1.000999999999999889865875957184471189975738525390 6
25
new BigDecimal( new Double("1.001").doubleValue() ) gives 1.000999999999999889865875957184471189975738525390 625
Results on Solaris Box
---------------------------------------------------------------------------
bash-3.00$java db2
08.02.0002
Database version is 08.02.0000
Testing value 1.001
native driver object is a class java.math.BigDecimal
value is 1.001
as getDouble it's 1.001 <<<<<<<<<< DIFFERENT!
native driver object is a class java.math.BigDecimal
value is 1.001 <<<<<<<<<< DIFFERENT!
as getDouble it's 1.001
double d = 1.001d gives 1.001
new Double("1.001").doubleValue() gives 1.001
they are equal.
new BigDecimal(1.001d) gives 1.000999999999999889865875957184471189975738525390 625
new BigDecimal( new Double("1.001").doubleValue() ) gives 1.000999999999999889865875957184471189975738525390 625
The program:
------------------------------------------------------------------------------------------
import java.io.*;
import java.util.*;
import java.net.*;
import java.sql.*;
import weblogic.common.*;
public class db2
{
public static void main(String argv[])
throws Exception
{
Connection c = null;
try
{
java.util.Properties props = new java.util.Properties();
Driver d = (Driver)Class.forName("COM.ibm.db2.jdbc.app.DB2Dri ver").newInstance();
props.put("user", "wls");
props.put("password", "wls");
props.put("DatabaseName", "wls");
String URL = "jdbc:db2:wls1";
c = d.connect(URL, props);
DatabaseMetaData dm = c.getMetaData();
System.out.println(dm.getDriverVersion());
System.out.println("Database version is " + dm.getDatabaseProductVersion() );
Statement s = c.createStatement();
try{s.executeUpdate("drop table joe");}catch (Exception ignore){}
s.executeUpdate("create table joe (bar decimal(4,3))");
s.executeUpdate("insert into joe values(1.001)");
PreparedStatement p = c.prepareStatement("insert into joe values(?)");
p.setDouble(1, new Double("1.001").doubleValue());
p.executeUpdate();
System.out.println("Testing value " + new Double("1.001").doubleValue() );
ResultSet r = s.executeQuery("select * from joe");
while (r.next())
{
System.out.println("native driver object is a " + r.getObject(1).getClass() );
System.out.println(" value is " + r.getObject(1) );
System.out.println("as getDouble it's " + r.getDouble(1) );
}
double d = 1.001d;
double dd = new Double("1.001").doubleValue();
System.out.println("double d = 1.001d gives " + d );
System.out.println("new Double(\"1.001\").doubleValue() gives " + dd );
if (d == dd)
System.out.println("they are equal." );
else
System.out.println("they are not equal." );
System.out.println("new BigDecimal(1.001d) gives " + new BigDecimal(1.001d) );
System.out.println("new BigDecimal( new Double(\"1.001\").doubleValue() ) gives "
+ new BigDecimal( new Double("1.001").doubleValue() ) );
}
catch (Exception e)
{ e.printStackTrace(); }
finally
{ try {c.close();}catch (Exception e){} }
}
}
15  2420 
Joe Weinstein wrote: Results on Linux Box
--------------------------------------------------------------
-bash-2.05b$ java db2
08.02.0001
Database version is 08.02.0000
Testing value 1.001
native driver object is a class java.math.BigDecimal
value is 1.001
as getDouble it's 1.0010000000000001 <<<<<<<<<< SEE
THIS! native driver object is a class java.math.BigDecimal
value is 1.001
as getDouble it's 1.0010000000000001 <<<<<<<<<< SEE
THIS! double d = 1.001d gives 1.001
new Double("1.001").doubleValue() gives 1.001
they are equal.
new BigDecimal(1.001d) gives
1.000999999999999889865875957184471189975738525390 6 25
new BigDecimal( new Double("1.001").doubleValue() ) gives
1.000999999999999889865875957184471189975738525390 625
Results on Solaris Box
---------------------------------------------------------------
bash-3.00$java db2
08.02.0002
Database version is 08.02.0000
Testing value 1.001
native driver object is a class java.math.BigDecimal
value is 1.001
as getDouble it's 1.001 <<<<<<<<<<
DIFFERENT! native driver object is a class java.math.BigDecimal
value is 1.001 <<<<<<<<<<
DIFFERENT!
as getDouble it's 1.001
double d = 1.001d gives 1.001
new Double("1.001").doubleValue() gives 1.001
they are equal.
new BigDecimal(1.001d) gives
1.000999999999999889865875957184471189975738525390 625 new BigDecimal( new
Double("1.001").doubleValue() ) gives
1.000999999999999889865875957184471189975738525390 625
------------------------------------------------------------------
You should compare the binary representation of the double value. I assume
that _those_ are identical and what you are seeing is due to varying
implementations in your JVMs when the double value is converted to a
string.
--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Joe Weinstein wrote: Hi. Below is a simple JDBC program to insert and extract
a numerical value. When ResultSet.getDouble() is called,
the same program produces different output on solaris
than it does on Linux.
String-Output of double/float values depends on the JVM.
But this isn't a problem of Java - its a problem we have since the
invention of floating point operations.
Thats why mercantile applications are using BCD, fixed point or simply
rounding every result to the precision needed.
Bernd
Thanks much. I think you're right. I'll do that.
thanks,
Joe
Knut Stolze wrote: Joe Weinstein wrote:
Results on Linux Box
--------------------------------------------------------------
-bash-2.05b$ java db2
08.02.0001
Database version is 08.02.0000
Testing value 1.001
native driver object is a class java.math.BigDecimal
value is 1.001
as getDouble it's 1.0010000000000001 <<<<<<<<<< SEE
THIS! native driver object is a class java.math.BigDecimal
value is 1.001
as getDouble it's 1.0010000000000001 <<<<<<<<<< SEE
THIS! double d = 1.001d gives 1.001
new Double("1.001").doubleValue() gives 1.001
they are equal.
new BigDecimal(1.001d) gives
1.0009999999999998898658759571844711899757385253 906 25
new BigDecimal( new Double("1.001").doubleValue() ) gives
1.0009999999999998898658759571844711899757385253 90625
Results on Solaris Box
---------------------------------------------------------------
bash-3.00$java db2
08.02.0002
Database version is 08.02.0000
Testing value 1.001
native driver object is a class java.math.BigDecimal
value is 1.001
as getDouble it's 1.001 <<<<<<<<<<
DIFFERENT! native driver object is a class java.math.BigDecimal
value is 1.001 <<<<<<<<<<
DIFFERENT!
as getDouble it's 1.001
double d = 1.001d gives 1.001
new Double("1.001").doubleValue() gives 1.001
they are equal.
new BigDecimal(1.001d) gives
1.0009999999999998898658759571844711899757385253 90625 new BigDecimal( new
Double("1.001").doubleValue() ) gives
1.0009999999999998898658759571844711899757385253 90625
------------------------------------------------------------------
You should compare the binary representation of the double value. I assume
that _those_ are identical and what you are seeing is due to varying
implementations in your JVMs when the double value is converted to a
string.
Bernd Hohmann wrote: Joe Weinstein wrote:
Hi. Below is a simple JDBC program to insert and extract
a numerical value. When ResultSet.getDouble() is called,
the same program produces different output on solaris
than it does on Linux.
String-Output of double/float values depends on the JVM.
But this isn't a problem of Java - its a problem we have since the
invention of floating point operations.
Thats why mercantile applications are using BCD, fixed point or simply
rounding every result to the precision needed.
Bernd
Thanks. I should have checked this out. I will.
Joe
Joe Weinstein wrote: Thanks. I should have checked this out. I will.
Glad to help. If you need more or something else - DB2 JDBC bothers me
since years :-)
Bernd
Hi Knut. I just rechecked the code I sent, and it includes
some stuff to verify whether the JVM itself is printing
stuff differently, and it's not. It's just the driver's
getDouble() that behaves differently.
If you see anything I missed about checking the
JVM itself, let me know what to try. Thanks
Joe
Statement s = c.createStatement();
try{s.executeUpdate("drop table joe");}catch (Exception ignore){}
s.executeUpdate("create table joe (bar decimal(4,3))");
s.executeUpdate("insert into joe values(1.001)");
PreparedStatement p = c.prepareStatement("insert into joe values(?)");
p.setDouble(1, new Double("1.001").doubleValue());
p.executeUpdate();
System.out.println("Testing value " + new Double("1.001").doubleValue() );
ResultSet r = s.executeQuery("select * from joe");
while (r.next())
{
System.out.println("native driver object is a " + r.getObject(1).getClass() );
System.out.println(" value is " + r.getObject(1) );
System.out.println("as getDouble it's " + r.getDouble(1) );
}
double d = 1.001d;
double dd = new Double("1.001").doubleValue();
System.out.println("double d = 1.001d gives " + d );
System.out.println("new Double(\"1.001\").doubleValue() gives " + dd );
if (d == dd)
System.out.println("they are equal." );
else
System.out.println("they are not equal." );
System.out.println("new BigDecimal(1.001d) gives " + new BigDecimal(1.001d) );
System.out.println("new BigDecimal( new Double(\"1.001\").doubleValue() ) gives "
+ new BigDecimal( new Double("1.001").doubleValue() ) );
Knut Stolze wrote: Joe Weinstein wrote:
Results on Linux Box
--------------------------------------------------------------
-bash-2.05b$ java db2
08.02.0001
Database version is 08.02.0000
Testing value 1.001
native driver object is a class java.math.BigDecimal
value is 1.001
as getDouble it's 1.0010000000000001 <<<<<<<<<< SEE
THIS! native driver object is a class java.math.BigDecimal
value is 1.001
as getDouble it's 1.0010000000000001 <<<<<<<<<< SEE
THIS! double d = 1.001d gives 1.001
new Double("1.001").doubleValue() gives 1.001
they are equal.
new BigDecimal(1.001d) gives
1.0009999999999998898658759571844711899757385253 906 25
new BigDecimal( new Double("1.001").doubleValue() ) gives
1.0009999999999998898658759571844711899757385253 90625
Results on Solaris Box
---------------------------------------------------------------
bash-3.00$java db2
08.02.0002
Database version is 08.02.0000
Testing value 1.001
native driver object is a class java.math.BigDecimal
value is 1.001
as getDouble it's 1.001 <<<<<<<<<<
DIFFERENT! native driver object is a class java.math.BigDecimal
value is 1.001 <<<<<<<<<<
DIFFERENT!
as getDouble it's 1.001
double d = 1.001d gives 1.001
new Double("1.001").doubleValue() gives 1.001
they are equal.
new BigDecimal(1.001d) gives
1.0009999999999998898658759571844711899757385253 90625 new BigDecimal( new
Double("1.001").doubleValue() ) gives
1.0009999999999998898658759571844711899757385253 90625
------------------------------------------------------------------
You should compare the binary representation of the double value. I assume
that _those_ are identical and what you are seeing is due to varying
implementations in your JVMs when the double value is converted to a
string.
Joe Weinstein wrote: Hi Knut. I just rechecked the code I sent, and it includes
some stuff to verify whether the JVM itself is printing
stuff differently, and it's not. It's just the driver's
getDouble() that behaves differently.
If you see anything I missed about checking the
JVM itself, let me know what to try. Thanks
Joe
Statement s = c.createStatement();
try{s.executeUpdate("drop table joe");}catch (Exception ignore){}
s.executeUpdate("create table joe (bar decimal(4,3))");
s.executeUpdate("insert into joe values(1.001)");
PreparedStatement p = c.prepareStatement("insert into joe
values(?)"); p.setDouble(1, new Double("1.001").doubleValue());
p.executeUpdate();
System.out.println("Testing value " + new
Double("1.001").doubleValue() ); ResultSet r =
s.executeQuery("select * from joe"); while (r.next())
{
System.out.println("native driver object is a " +
r.getObject(1).getClass() ); System.out.println(" value is " +
r.getObject(1) ); System.out.println("as getDouble it's " +
r.getDouble(1) );
}
double d = 1.001d;
double dd = new Double("1.001").doubleValue();
System.out.println("double d = 1.001d gives " + d );
System.out.println("new Double(\"1.001\").doubleValue() gives " +
dd ); if (d == dd)
System.out.println("they are equal." );
else
System.out.println("they are not equal." );
System.out.println("new BigDecimal(1.001d) gives " + new
BigDecimal(1.001d) ); System.out.println("new BigDecimal( new
Double(\"1.001\").doubleValue() ) gives "
+ new BigDecimal( new Double("1.001").doubleValue() ) );
You are not looking at the binary representation of the numbers. Everything
else are just the usual rounding issues related to the conversion between
the internal binary format and the external decimal format.
You should also read this article to understand how floating point numbers
are represented in today's computer systems: http://cch.loria.fr/documentation/IE...M/goldberg.pdf
--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Knut Stolze wrote: Joe Weinstein wrote:
Hi Knut. I just rechecked the code I sent, and it includes
some stuff to verify whether the JVM itself is printing
stuff differently, and it's not. It's just the driver's
getDouble() that behaves differently.
If you see anything I missed about checking the
JVM itself, let me know what to try. Thanks
Joe
Statement s = c.createStatement();
try{s.executeUpdate("drop table joe");}catch (Exception ignore){}
s.executeUpdate("create table joe (bar decimal(4,3))");
s.executeUpdate("insert into joe values(1.001)");
PreparedStatement p = c.prepareStatement("insert into joe
values(?)"); p.setDouble(1, new Double("1.001").doubleValue());
p.executeUpdate();
System.out.println("Testing value " + new
Double("1.001").doubleValue() ); ResultSet r =
s.executeQuery("select * from joe"); while (r.next())
{
System.out.println("native driver object is a " +
r.getObject(1).getClass() ); System.out.println(" value is " +
r.getObject(1) ); System.out.println("as getDouble it's " +
r.getDouble(1) );
}
double d = 1.001d;
double dd = new Double("1.001").doubleValue();
System.out.println("double d = 1.001d gives " + d );
System.out.println("new Double(\"1.001\").doubleValue() gives " +
dd ); if (d == dd)
System.out.println("they are equal." );
else
System.out.println("they are not equal." );
System.out.println("new BigDecimal(1.001d) gives " + new
BigDecimal(1.001d) ); System.out.println("new BigDecimal( new
Double(\"1.001\").doubleValue() ) gives "
+ new BigDecimal( new Double("1.001").doubleValue() ) );
You are not looking at the binary representation of the numbers. Everything
else are just the usual rounding issues related to the conversion between
the internal binary format and the external decimal format.
Actually, yes I am. I am banking off the spec for BigDecimal:
"Translates a double into a BigDecimal which is the exact decimal
representation of the double's binary floating-point value."
I'll see if I can make some more additions to make it clearer to me.
thanks,
Joe
You should also read this article to understand how floating point numbers
are represented in today's computer systems:
http://cch.loria.fr/documentation/IE...M/goldberg.pdf
Joe Weinstein wrote: Actually, yes I am. I am banking off the spec for BigDecimal:
"Translates a double into a BigDecimal which is the exact decimal
representation of the double's binary floating-point value."
The issue I still have with this is that you are dealing with different
representations of floating point numbers and that you are still not
comparing the internal binary IEEE754 representation.
The Java manual ( http://java.sun.com/j2se/1.4.2/docs/api/index.html) gives a
nice example, which most probably applies to your question:
-----------------------------------------------------
public BigDecimal(double val)
Translates a double into a BigDecimal. The scale of the BigDecimal is
the smallest value such that (10scale * val) is an integer.
Note: the results of this constructor can be somewhat unpredictable. One
might assume that new BigDecimal(.1) is exactly equal to .1, but it is
actually equal to .1000000000000000055511151231257827021181583404541 015625.
This is so because .1 cannot be represented exactly as a double (or, for
that matter, as a binary fraction of any finite length). Thus, the long
value that is being passed in to the constructor is not exactly equal
to .1, appearances notwithstanding.
The (String) constructor, on the other hand, is perfectly predictable:
new BigDecimal(".1") is exactly equal to .1, as one would expect.
Therefore, it is generally recommended that the (String) constructor be
used in preference to this one.
-----------------------------------------------------
I would recommend that you try "Double.compare" or
"Double.doubleToRawLongBits" instead.
--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Knut Stolze wrote: Joe Weinstein wrote:
Actually, yes I am. I am banking off the spec for BigDecimal:
"Translates a double into a BigDecimal which is the exact decimal
representation of the double's binary floating-point value."
The issue I still have with this is that you are dealing with different
representations of floating point numbers and that you are still not
comparing the internal binary IEEE754 representation.
The Java manual (http://java.sun.com/j2se/1.4.2/docs/api/index.html) gives a
nice example, which most probably applies to your question:
-----------------------------------------------------
public BigDecimal(double val)
Translates a double into a BigDecimal. The scale of the BigDecimal is
the smallest value such that (10scale * val) is an integer.
Note: the results of this constructor can be somewhat unpredictable. One
might assume that new BigDecimal(.1) is exactly equal to .1, but it is
actually equal to .1000000000000000055511151231257827021181583404541 015625.
This is so because .1 cannot be represented exactly as a double (or, for
that matter, as a binary fraction of any finite length). Thus, the long
value that is being passed in to the constructor is not exactly equal
to .1, appearances notwithstanding.
The (String) constructor, on the other hand, is perfectly predictable:
new BigDecimal(".1") is exactly equal to .1, as one would expect.
Therefore, it is generally recommended that the (String) constructor be
used in preference to this one.
-----------------------------------------------------
I would recommend that you try "Double.compare" or
"Double.doubleToRawLongBits" instead.
I have also compared the doubles. It is only the Linux IBM getDouble()
method that fails. The getBigDecimal obviously gets the correct input
from the DBMS and produces an exact 1.001 in both cases, so we can
assume that the getDouble() has the same input. Using "1.001" as well
as the double approximation for 1.001 in every way I can on both
platforms, and I always get the same long decimal approximation on
Linux as I do on Solaris. It's not unpredictable:
1.001000000000000111910480882215779274702072143554 6875. I believe the
problem is somewhere in the IBM driver's code, that it comes up with
1.0010000000000001.
I may be taking up too much of your time, but I thank you for what you've
posted so far. Can you direct me to any IBM forum that might be more
closely interested in JDBC? I would pursue it there. Or if you have some
generic Java code that you'd suggest to prove/disprove your theory that
it's the JVM, I'll run it in both places.
thanks again,
Joe Weinstein at BEA
Oh, I just checked that last reply, sorry: The exact decimal
representation of the double I get on both platforms for
1.001, either directly declared ar via a string constructor
or the getDouble() on Solaris, is actually:
1.000999999999999889865875957184471189975738525390 625
On both platforms, Linux and Solaris, the double I construct
with those bits, or from the Solaris getDouble() prints as
1.001.
The value I misquoted in the last post was what I get
by displaying the bits exactly of the double that the
driver's getDouble() on linux returned. It prints as
1.0010000000000001
it's bits (as decimal) are:
1.001000000000000111910480882215779274702072143554 6875
Joe Weinstein wrote: I have also compared the doubles. It is only the Linux IBM getDouble()
method that fails. The getBigDecimal obviously gets the correct input
from the DBMS and produces an exact 1.001 in both cases, so we can
assume that the getDouble() has the same input.
Have you used the "Double.doubleToRawLongBits" and printed that number?
This is giving you the internal binary representation.
--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Knut Stolze wrote: Joe Weinstein wrote:
I have also compared the doubles. It is only the Linux IBM getDouble()
method that fails. The getBigDecimal obviously gets the correct input
from the DBMS and produces an exact 1.001 in both cases, so we can
assume that the getDouble() has the same input.
Have you used the "Double.doubleToRawLongBits" and printed that number?
This is giving you the internal binary representation.
Hi, yes I did. If the internal binary representation was different in any way,
then the BigDecimal constructor, which makes an exact decimal version of the
given double, would also differ. On both platforms, the double that prints as
1.001 has the same raw bits pattern as well as BigDecimal conversion:
doubleToRawLongBits gives 4607186922399644778
for a BigDecimal value 1.000999999999999889865875957184471189975738525390 625
This is the same for the Solaris getDouble().
It is *only* the Double returned by the driver's
getDouble() on Linux that prints as 1.0010000000000001,
with a raw bits pattern of 4607186922399644779,
which makes a BigDecimal 1.001000000000000111910480882215779274702072143554 6875
I can send you or anyone else in IBM the standalone
repro.
thanks
Joe Weinstein at BEA Systems
Joe Weinstein wrote: Hi, yes I did. If the internal binary representation was different in any
way, then the BigDecimal constructor, which makes an exact decimal version
of the given double, would also differ. On both platforms, the double that
prints as 1.001 has the same raw bits pattern as well as BigDecimal
conversion: doubleToRawLongBits gives 4607186922399644778
It is *only* the Double returned by the driver's
getDouble() on Linux that prints as 1.0010000000000001,
with a raw bits pattern of 4607186922399644779,
Now I got it, I believe. Sorry that I was a bit too dense until now.
I tried this myself, and on Linux I get the raw bits: 4607186922399644778
from the following SQL statement:
SELECT DECIMAL(1.001, 5, 3) FROM sysibm.sysdummy1
I'm using the "com.ibm.db2.jcc.DB2Driver" and a type 4 driver.
So it would be a good idea to know more details about your environment, i.e.
DB2 version and FP level, etc.
--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Knut Stolze wrote: Joe Weinstein wrote:
Hi, yes I did. If the internal binary representation was different in any
way, then the BigDecimal constructor, which makes an exact decimal version
of the given double, would also differ. On both platforms, the double that
prints as 1.001 has the same raw bits pattern as well as BigDecimal
conversion: doubleToRawLongBits gives 4607186922399644778
It is *only* the Double returned by the driver's
getDouble() on Linux that prints as 1.0010000000000001,
with a raw bits pattern of 4607186922399644779,
Now I got it, I believe. Sorry that I was a bit too dense until now.
I tried this myself, and on Linux I get the raw bits: 4607186922399644778
from the following SQL statement:
SELECT DECIMAL(1.001, 5, 3) FROM sysibm.sysdummy1
I'm using the "com.ibm.db2.jcc.DB2Driver" and a type 4 driver.
So it would be a good idea to know more details about your environment, i.e.
DB2 version and FP level, etc.
Thanks much. Database version is 08.02.0000. The driver is type-2.
That is the likely reason for the bug (platform dependence)
Joe This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Axel Dachtler |
last post by:
Hello,
my Java-program can't load the JDBC driver.
I always get a java.lang.NoClassDefFoundError when I run it.
The JDBC Driver is in the directory: C:\programs\ora92\jdbc\lib
I think I...
|
by: Priya |
last post by:
Hi,
I am having some problem with DB2 Universal JDBC driver.
1. The method getColumnType(columnNumber)of ResultSetMetaData always
returns zero.
2. The method getColumnDisplaySize(ColumnNum)...
|
by: Dani |
last post by:
Hi everyone
Description of the problem:
Using a PreparedStatement to write down an integer (int) plus a
timestamp for testing purposes. When read out again the integer looks
very different. We...
|
by: Bing |
last post by:
Hi,
I am configuring the same DB2 v8.1 JDBC universal driver (db2jcc.jar
and db2jcc_license_cisuz.jar) from DB2 SP5 fix pack under WSAD 5.1.x
environment and WebSphere application Server 5.0.2...
|
by: Raquel |
last post by:
Read this about the Universal JDBC Driver....
"In a Type 2 mode, the Universal JDBC driver provides local
application performance gains (because it avoids using TCP/IP protocol
to communicate to...
|
by: eugene |
last post by:
Happy Christmas to all (who celebrate)!
It's still not clear to me... when in a java stored procedure it says:
conn = DriverManager.getConnection("jdbc:default:connection");
what driver DB2...
|
by: kavallin |
last post by:
I wonder if anyone has compared the db2 universal jdbc driver type 2
and 4 with the legacy db2 driver. Which one is the best to use ? I'm
working in a project where the envm looks like this
...
|
by: Marc Melancon |
last post by:
hi,
Does MS2005 JDBC Driver 1.1 support integrated security on Solaris and if so
how?
Thanks,
MarcM
|
by: dunleav1 |
last post by:
How can I be sure that DB2_LINUXAIO is working properly in DB 9 FP3?
The parameter db2_linuxaio was depreciated from the base version to
FP3 and my performance tests have shown a decrease in...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
