Problem with JDBC MSSQL
Dennis Neetix
I'm running an applet which should have a connection to a microsoft sql
server 2000. I've downloaded the JDBC Driver from the Microsoft site and
installed it. Now everytime I start the applet the console throws the
following message out:
java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]Error
establishing socket.
at com.microsoft.jdbc.base.BaseExceptions.createException(Unknown Source)
at com.microsoft.jdbc.base.BaseExceptions.getException(Unknown Source)
at com.microsoft.jdbc.base.BaseExceptions.getException(Unknown Source)
at com.microsoft.jdbc.sqlserver.tds.TDSConnection.<init>(Unknown Source)
at com.microsoft.jdbc.sqlserver.SQLServerImplConnection.open(Unknown
Source)
at com.microsoft.jdbc.base.BaseConnection.getNewImplConnection(Unknown
Source)
at com.microsoft.jdbc.base.BaseConnection.open(Unknown Source)
at com.microsoft.jdbc.base.BaseDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at Zeiterfassung.openDB(Zeiterfassung.java:74)
at Zeiterfassung.init(Zeiterfassung.java:234)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I searched already in many forums in the net but I didn't get a answer or
hint. Does anybody know this error?
Bye,
Dennis
Robert Klemme
"Dennis Neetix" <dennis...@web.de> schrieb im Newsbeitrag
news:d0n2lh$e25$02$1...@news.t-online.com...
Normal applets run in a sandbox which means they can only connect back to
the server they were downloaded from. If you want to do such things you
can sign the applet thus relaxing security restrictions.
However, I recommend not to use JDBC from an applet. Better use a
specialized protocol between applet and server (a simple solution could be
to send serialized objects via HTTP).
Side note: I really wonder why this topic comes up again and again. By
now it should be widely known what applets are and especially what they
are not.
Regards
robert
dar7yl
news:398kfhF...@individual.net...
>
> "Dennis Neetix" <dennis...@web.de> schrieb im Newsbeitrag
> news:d0n2lh$e25$02$1...@news.t-online.com...
>> Hi,
>>
>> I'm running an applet which should have a connection to a microsoft sql
>> server 2000. I've downloaded the JDBC Driver from the Microsoft site and
>> installed it. Now everytime I start the applet the console throws the
>> following message out:
>>
>> java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]Error
>> establishing socket.
> or
>> hint. Does anybody know this error?
>
> Normal applets run in a sandbox which means they can only connect back to
> the server they were downloaded from. If you want to do such things you
> can sign the applet thus relaxing security restrictions.
>
> However, I recommend not to use JDBC from an applet. Better use a
> specialized protocol between applet and server (a simple solution could be
> to send serialized objects via HTTP).
>
> Side note: I really wonder why this topic comes up again and again. By
> now it should be widely known what applets are and especially what they
> are not.
I don't agree with your recommendation. I have had no problem using JDBC
from an applet.
Your idea of using a specialized protocol between applet and server just
adds a layer of complexity to an already obfusticated concept. A properly
designed application can operate quite well as a database client.
As you obviously can't grasp, an applet is simply a class that can be
executed from within a http: browser. It does have some restrictions that
you have to
deal with, but nothing that can't be handled (after some delving).
regards,
Dar7yl
dar7yl
news:d0n2lh$e25$02$1...@news.t-online.com...
> I'm running an applet which should have a connection to a microsoft sql
> server 2000. I've downloaded the JDBC Driver from the Microsoft site and
> installed it. Now everytime I start the applet the console throws the
> following message out:
>
> java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]Error
> establishing socket.
Right now, we don't have enough information about the error to solve it.
You will have to intercept the exception, and dig out more info from it.
So, first, surround your connect(...) with a try/catch block.
see http://java.sun.com/j2se/1.4.2/docs/api//java/sql/SQLException.html
<code>
try
{
connect(...); // you fill in the details
}
catch ( java.sql.SQLException ex )
{
System.out.println("SQL exception: " + ex );
System.out.println(" error code is " + ex.getErrorCode() );
System.out.println(" state is " + ex.getSQLState() );
System.out.println("chained exception: " + ex.getNextException());
// rest of exception handling code...
}
</code>
Then you have to look up the error code in your jdbc driver docs
(ask B.Gates nicely:) to find out exactly the problem.
Some possible problems encountered:
- trying to open a socket onto another server.
- can't find database server
- can't login to database (database name, user name, password have to
match)
Hope that helps.
regards,
Dar7yl
Robert Klemme
"dar7yl" <no_r...@accepted.org> schrieb im Newsbeitrag
news:HJbYd.22428$KI2.8936@clgrps12...
Well, I didn't say it's impossible.
> Your idea of using a specialized protocol between applet and server just
> adds a layer of complexity to an already obfusticated concept.
I don't know which of the concepts involved you call "obfuscated". Apart
from that, you forget to mention that an additional layer has indeed
benefits. Layering is a common technique in the area of software
engineering to separate concerns and keep things manageable. For example
it gives you more flexibility and control over communication which is
important for an applet that is used via a WAN as the internet (=
potentially slow and high latency). And you don't have to load driver
classes and you can easily use another persistent storage instead of JDBC.
...
> A properly
> designed application can operate quite well as a database client.
You have to keep in mind that you have no control at all about the way a
JDBC driver talks to the database. There might well be a lot of short
messages which can lead to a considerable slowdown of the applet's
operation of used via a WAN.
> As you obviously can't grasp,
How do you know?
> an applet is simply a class that can be
> executed from within a http: browser. It does have some restrictions
that
> you have to
> deal with, but nothing that can't be handled (after some delving).
Again, I didn't say it's impossible; I just recommend to not use JDBC from
an applet because the drawbacks outweight the advantages.
robert
dar7yl
>> > However, I recommend not to use JDBC from an applet. Better use a
>> > specialized protocol between applet and server (a simple solution
>> > could be to send serialized objects via HTTP).
> "dar7yl" schrieb im Newsbeitrag
>> I don't agree with your recommendation. I have had no problem using
>> JDBC from an applet.
> Well, I didn't say it's impossible.
>
>> Your idea of using a specialized protocol between applet and server just
>> adds a layer of complexity to an already obfusticated concept.
>
> I don't know which of the concepts involved you call "obfuscated". Apart
> from that, you forget to mention that an additional layer has indeed
> benefits. Layering is a common technique in the area of software
> engineering to separate concerns and keep things manageable. For example
> it gives you more flexibility and control over communication which is
> important for an applet that is used via a WAN as the internet (=
> potentially slow and high latency). And you don't have to load driver
> classes and you can easily use another persistent storage instead of JDBC.
>
>> A properly designed application can operate
>> quite well as a database client.
>
> You have to keep in mind that you have no control at all about the way a
> JDBC driver talks to the database. There might well be a lot of short
> messages which can lead to a considerable slowdown of the applet's
> operation of used via a WAN.
IMHO, "Enterprise" is a term used when you split an application into two
parts so you can charge twice as much as the old one, and get half the
performance, in twice the time.
Yes, you could have dismal performance if you don't understand how
the jdbc driver is communicating with the database server. However,
it's been my experience that a modern database driver has excellent
performance over the net. When you get down to it, the information
you want to display is usually what you have scraped off the database.
If you compose your queries properly, and pay attention to the
capabilities of the database, the actual amount of data transferred can
be quite efficient. In my experience, most of the lag time I observe is
due to database processing; not transfer time. The response times
are quite acceptable in most cases.
Most modern drivers are quite good at transferring the data back and
forth between the client and the server. You are still going to get
database
latency no matter what level you are talking at. Also, with middleware, you
have to translate the data into another format, which can add bulk without
corresponding increases in functionality.
I have had good performance running applications in a variety of
environments.
Of course, best performance is running on the local machine, with LAN
running
a close second. Even running on a WAN using VPN over the internet is
quite acceptable (We regularly run between Vancouver (BC) and Prince Rupert
using SonicWall VPN over ADSL). The response is still comparable to the old
VB
program which used a local Access database. In some instances it has sped
up,
which I attribute to MySQL's better handling of complex joins.
regards,
Dar7yl
Daniel Hagen
> "Robert Klemme" <bob....@gmx.net> wrote in message
> news:398kfhF...@individual.net...
>
>>"Dennis Neetix" <dennis...@web.de> schrieb im Newsbeitrag
>>news:d0n2lh$e25$02$1...@news.t-online.com...
>>
>>> following message out:
>>>
>>>java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]Error
>>>establishing socket.
>>
>>the server they were downloaded from. If you want to do such things you
>>can sign the applet thus relaxing security restrictions.
That might be one reason for the error (though the error message one
would except in this would be a SecurityException).
Other common errors are that
- The SQL Server is not running
- The wrong IP/Port was used in the connection String or, most common
- The SQL Server does not accept TCP/IP connections because it is not
configured to do so (e.g. in an MSDE standard installation) or because
it is running on Windows Server 2003 without MS SQL Server SP 3 installed
>>However, I recommend not to use JDBC from an applet. Better use a
>>specialized protocol between applet and server (a simple solution could be
>>to send serialized objects via HTTP).
>
> I don't agree with your recommendation. I have had no problem using JDBC
> from an applet.
>
> Your idea of using a specialized protocol between applet and server just
> adds a layer of complexity to an already obfusticated concept. A properly
> designed application can operate quite well as a database client.
I don't agree with your disagreement ;-)
In a well designed application that layer should not add any complexity
to the application in general.
But the main reason for *not* using JDBC from an applet is - apart from
the need to sign your applet, transmit the database user credentials to
the client in some form, hardly being able to encrypt traffic between
applet and database, transmitting information about the database
structure to the client, ... - the resulting infrastructure problem.
If you want to access the SQL Server from an applet, the SQL Server Port
must be open to the applet in order to accept incoming connections
(which is not a good thing, especially on the internet) and the applet
must be able to access the SQL Server directly.
Both creates problems because most Servers are protected by firewalls
and some firewalls on the client side block outgoing access to ports
other than the usual internet stuff. This is also true for many intranet
setups.
If you want to spare yourself that hassle, you *have* to stick to the
http connection your applet was served from, because this connection is
the only one you know to be working.
Regards
Daniel