| Reference | Help | Introduction | Slide Show | Class Hierarchy | InterClient | ||
| PREV | NEXT | FRAMES | NO FRAMES | ||
First, verify that the installation has appended your CLASSPATH with the interclient.jar file.
Second, on Windows NT/95, select the InterServer Configuration
Utility icon in the InterClient program group and start the
InterServer service or application (usually, but not necessarily,
on your InterBase server). On Unix the interserver service is
started automatically by inetd if your /etc/services and
/etc/inetd.conf are configured properly.
Finally, on Windows NT/95, select the Communication Diagnostics icon from the InterClient program group. If Java is installed on your local machine and interclient.jar is in your CLASSPATH, then a GUI will appear for making a test connection using the locally installed driver. Alternatively, and on Unix, you may invoke the Communication Diagnostics Utility from the command line using
java interbase.interclient.utils.CommDiag
CommDiag may also be run as an applet on clients in which neither the JDK nor InterClient is installed. Using a Java enabled browser, browse CommDiag.html off a web server which has InterClient deployed. If you run InterClient applets such as CommDiag through a browser, then you may need to remove the interclient.jar from your local CLASSPATH to avoid a security exception. A browser's default security policy may only allow socket connections to the host which is the source of the class file which is attempting the connection. So the security manager needs to be sure that the source host of the downloaded InterClient class files is the same as the database server host. If the interclient.jar is being picked up from your local disk, rather than being downloaded along with an applet such as CommDiag, then this may be difficult for the security manager to determine.
You may also run CommDiag through the appletviewer.
On Unix:
unset CLASSPATH
appletviewer CommDiag.html
On Windows 95/NT:
set CLASSPATH=
appletviewer CommDiag.html
You may need to unset your CLASSPATH temporarily in your command
session when viewing a local applet; otherwise you could receive a
java.lang.IllegalAccessError. CommDiag.html contains
an applet tag which references the interclient.jar archive.
Depending on your browser's security policy, untrusted applets may not be allowed to open network connections to arbitrary hosts, except for the host that provided the .class files. This is either the host where the html page came from, or the host specified in the codebase parameter in the applet tag, with codebase taking precendence. Under this security policy, untrusted applets will only operate if InterServer is installed on the same web server host that serves the interclient.jar file. If you choose to deploy InterServer on another host then you may need to digitally sign your applet together with the interclient.jar file so that the entire applet is trusted. InterServer is *not* involved in the certification process, its an issue between the browser and the downloaded jar. Browsers are all configured differently, so see the vendor-specific documentation for your browser. Some browsers (eg. HotJava) can be configured to allow arbitrary socket connections even for untrusted applets, others (eg. Netscape) have their own proprietary security api to allow an untrusted applet to request privileges from the browser.
Be sure to name the originating host exactly as it was specified when the applet was loaded into the browser. That is, if you load an HTML page using the URL
http://foo.state.edu/~me/CommDiag.html
then your applet will be able to connect to its host only by using
the name foo.state.edu in the jdbc URL
jdbc:interbase://foo.state.edu//databases/employee.gdb
Using the IP address for foo.state.edu won't work, and using a
"shorthand" form of the host name, like foo.state instead of
foo.state.edu, won't work.
This exception is issued by the JDBC Driver Manager and usually occurs during a call to DriverManager.getConnection(). The cause can be failing to load the appropriate JDBC driver before calling getConnection(), or specifying an invalid JDBC URL - one that isn't recognized by any loaded JDBC driver.
This error can also occur due to a bug in the JDK 1.1.x with Class.forName(). Because of a race condition in the class loader, it is sometimes possible that the class loader is prevented from executing the static section of code in the driver class. This would prevent the loaded driver class from registering itself with the driver manager. So Class.forName () may appear to succeed with no exception thrown, but the driver may not be registered with the driver manager. A work around is to obtain a connection from an explicitly constructed driver instance as follows:
java.sql.Driver d = new interbase.interclient.Driver ();
java.sql.Connection c = d.connect ("jdbc:interbase://server/c:/databases/atlas.gdb",
"sysdba", "masterkey");
Here are some typical reasons for getting the no suitable driver error:
Class.forName ("interbase.interclient.Driver");
DriverManager.getConnection ("jdbc:interbase://server/c:/databases/atlas.gdb", ...);
Only one customer has reported this problem, and its cause is not currently known.
In general, interserver errors are relayed back to InterClient and surfaced via an SQLException. However, if the socket is unexpectedly disconnected, or some other error occurs on the socket, then relay of the error message back to the client over the same socket may be impossible. So the purpose of the interserver.log file is for the logging of messages that cannot be relayed back to InterClient.
Messages logged to the interserver.log file are usually innocuous and caused by client application neglect to close the socket gracefully using the Server.close() methods. InterServer spends its idle time waiting for requests from InterClient. If InterClient terminates abruptly without using Connection.close() then InterServer will detect an error on the socket, and log a message to the interserver.log file. This is of no real concern to the user, as the connection is closed, just not in a graceful manner.
However, socket failures could be caused for more insidious reasons, such as someone cutting the network wire with a pair of scissors. In such case, a message to interserver.log is logged since there is no way to relay an exception back to InterClient.
Here are the message codes which may be logged to the interserver.log file. The integer code simply indicates the exact location in the InterServer source where the message originated.
| JDBC/Net [100-199] | Unable to read bytes from socket |
| JDBC/Net [200-299] | Unable to write bytes to socket |
| Reference | Help | Introduction | Slide Show | Class Hierarchy | InterClient | ||
| PREV | NEXT | FRAMES | NO FRAMES | ||