Use your favorite .zip utility to extract all files, preserving the directory structure contained in the .zip-file; the .jar-files are in the file encryptedJars.zip. Then read and accept the License Agreement on your local computer system, after which you will get the password to extract the .jar-files from their zip. The .jar-file marked JDK1 is for JDK 1.1.x, the other for Java 2 (JDK 1.2.x and above).
Once again, the password is NOT online. The password is in the download only. Once downloaded, you should unzip all files, read and accept the License Agreement (license.htm) that is contained in the download (it is the same agreement as the one you may just have read online, but the <ACCEPT> button action is different). When you press (click on) the <ACCEPT> button, you will be presented the password to unpack the .jar files.
The reason for this procedure is simple. While our official distribution site enforces acceptance of the License Agreement before downloading, other distribution sites do not. Therefor we ask you to accept the downloaded License Agreement before giving you the password.
import be.arci.math.*;or, if you use java.math.BigInteger as well, replace
import java.math.BigInteger; import be.arci.math.*;
The answer is simple and fast, and requires little coding:
This is not difficult to understand. Except maybe for a 100% pure Java DBMS, a DBMS that implements the SQL types DECIMAL and NUMERIC will not represent them internally as java.math.BigDecimal objects, but in some proprietary format (very often some form of BCD or 'packed decimal'). Internal selection and sorting logic will work on the internal representation and in native code. The java.math.BigDecimal class is needed only in response to your calls to ResultSet.getBigDecimal(), CallableStatement.getBigDecimal() or PreparedStatement.setBigDecimal(). Now only a few Java classes like String are defined in JNI (the native code interface), so there is no sound way for the DBMS (apart maybe from running a modified JVM) to construct or interpret Java objects like BigDecimal in native code. Instead, your DBMS has to offer or ask the Java part of the JDBC driver a String or byte array. Therefor, rather than letting the Java part of the driver construct a java.math.BigDecimal from that String, you can just as valid (and faster) construct an ArciMath BigDecimal from it yourself.