pshortland
asked on
Network error IOException when calling SQL from Applet
Think I am very close on my mission to have an applet accessing my SQL database !
My applet is called by this code...
<APPLET
CODEBASE = "."
CODE = "app2.sqlapp.class"
NAME = "TestApplet"
WIDTH = 800
HEIGHT = 300
HSPACE = 0
VSPACE = 0
ALIGN = top
archive = "jtds-1.2.jar">
>
</APPLET>
The applet displays ok but gives this error message...
java.sql.SQLException: Network error IOException: Could not create socket
My sql code in the applet calling the sql statement is...
public String getData() {
Connection con = null;
try {
String driver = "net.sourceforge.jtds.jdbc .Driver";
Class.forName(driver).newI nstance();
}
catch( Exception e ) {
System.out.println(e);
return e+"";
}
try {
con = DriverManager.getConnectio n("jdbc:jt ds:sqlserv er://DHSQL 05:1433;us er=user;pa ssword=pas sy");
Statement select = con.createStatement();
ResultSet result = select.executeQuery ("SELECT SALES FROM A_Digital_week_store WHERE (CST_CNTR_CD = 2409) AND (FNCL_END_YR = 2008) AND (FNCL_WK_NUM = 4)");
result.next();
String val = result.getString(1);
return val;
}
catch( Exception e ) {
e.printStackTrace();
return e+"";
}
finally {
if( con != null ) {
try { con.close(); }
catch( Exception e ) { e.printStackTrace(); }
}
}
}
}
I have the driver jar file on the web server in the same folder as the java class.
Any tips to finish this off ?
My applet is called by this code...
<APPLET
CODEBASE = "."
CODE = "app2.sqlapp.class"
NAME = "TestApplet"
WIDTH = 800
HEIGHT = 300
HSPACE = 0
VSPACE = 0
ALIGN = top
archive = "jtds-1.2.jar">
>
</APPLET>
The applet displays ok but gives this error message...
java.sql.SQLException: Network error IOException: Could not create socket
My sql code in the applet calling the sql statement is...
public String getData() {
Connection con = null;
try {
String driver = "net.sourceforge.jtds.jdbc
Class.forName(driver).newI
}
catch( Exception e ) {
System.out.println(e);
return e+"";
}
try {
con = DriverManager.getConnectio
Statement select = con.createStatement();
ResultSet result = select.executeQuery ("SELECT SALES FROM A_Digital_week_store WHERE (CST_CNTR_CD = 2409) AND (FNCL_END_YR = 2008) AND (FNCL_WK_NUM = 4)");
result.next();
String val = result.getString(1);
return val;
}
catch( Exception e ) {
e.printStackTrace();
return e+"";
}
finally {
if( con != null ) {
try { con.close(); }
catch( Exception e ) { e.printStackTrace(); }
}
}
}
}
I have the driver jar file on the web server in the same folder as the java class.
Any tips to finish this off ?
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
IOW the applet should originate from DHSQL05
ASKER
DHSQL05 is a SQL server though, not a web server. I presume the applet has to come from a web server ? If so then it needs to be signed ?
It does need to come from a web server. If there's no web server on that host you'll need to sign it
ASKER
and I thought it was nearly done !
Is signing easy and free ? or hard and expensive !
Is signing easy and free ? or hard and expensive !
Hi,
The "Connection refused" exception is thrown by jTDS when it is unable to connect to the server. There may be a number of reasons why this could happen:
The server name is misspelled or the port number is incorrect.
SQL Server is not configured to use TCP/IP. Either enable TCP/IP from SQL Server's Network Utility app or have jTDS connect via named pipes (see the URL format for information on how to do this).
There is a firewall blocking port 1433 on the server.
To check whether TCP/IP is enabled and the port is not blocked you can use "telnet <server_host> 1433". Until telnet doesn't connect, jTDS won't either. If you can't figure out why, ask your network administrator for help.
http://jtds.sourceforge.net/faq.html#connectionRefused
R.K
The "Connection refused" exception is thrown by jTDS when it is unable to connect to the server. There may be a number of reasons why this could happen:
The server name is misspelled or the port number is incorrect.
SQL Server is not configured to use TCP/IP. Either enable TCP/IP from SQL Server's Network Utility app or have jTDS connect via named pipes (see the URL format for information on how to do this).
There is a firewall blocking port 1433 on the server.
To check whether TCP/IP is enabled and the port is not blocked you can use "telnet <server_host> 1433". Until telnet doesn't connect, jTDS won't either. If you can't figure out why, ask your network administrator for help.
http://jtds.sourceforge.net/faq.html#connectionRefused
R.K
>>Is signing easy and free ? or hard and expensive !
Yes. Generate your own cert and you can also use Ant to make signing easier
Yes. Generate your own cert and you can also use Ant to make signing easier
SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
Thanks objects.
I am pretty restricted in options as this is an intranet solution on servers we do not have admin control over. Option 1 is therefore not possible, option 2 looks the way to go if the client machines will work with a test certificate, if not I guess I may have to use an Access db on the web server as I can not install it as an app on any of the client terminals.
I am pretty restricted in options as this is an intranet solution on servers we do not have admin control over. Option 1 is therefore not possible, option 2 looks the way to go if the client machines will work with a test certificate, if not I guess I may have to use an Access db on the web server as I can not install it as an app on any of the client terminals.
>>looks the way to go if the client machines will work with a test certificate
They will if you follow what i suggested. If the users don't trust a self-generated cert, there's something distinctly wrong with office politics ;-)
They will if you follow what i suggested. If the users don't trust a self-generated cert, there's something distinctly wrong with office politics ;-)
if its an intranet then a test cert should be ok, assuming your users will trust it.
ASKER
Hmmm, my 'users' have pretty much no function terminals, certainly no admin rights etc. Are they likely to be able to use any cert ?
yes, any cert will work ok.
ASKER
Ok, test cert signing today. Will report back soon !
ASKER
Accepted this Q as need to raise a new one to progress signing.
:-)