2

I'm trying to learn some basic JDBC.

  • I've created a JavaDB server and made a Java program where i can read and alter some tables in the database.
  • I thought it would be a fun next step to be able to connect to the server from another computer running on the same network, or even from the internet if it's similar.
  • So far I’ve just tried opening project on another computer to see if it would connect to the localhost, but would expected it to be too easy...

The current db name is "jdbc:derby://localhost:1527/test;user=db;password=db".

  1. Could i replace the localhost with my ipv4 address to connect locally? or
  2. Do i really need the router's IP and do some port forwarding?

Connecting locally is really what I need. If this is easier, then that's what i would like to do.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
User892313
  • 225
  • 3
  • 19

4 Answers4

0

You need to use either the hostname or the IP of the box you want to connect to:

URI: jdbc:derby://<hostname_or_ip>:1527/test;user=db;password=db

Replace <hostname_or_ip> for the real value and you are good to go.

x80486
  • 6,627
  • 5
  • 52
  • 111
  • Thanks. It crashes and says the connection is refused, i tried googling it and it seems to be an issue when the server is not running or a firewall is blocking the connection. I know the server is running, because it works with localhost, and i don't have any antivirus aside from the standard windows firewall. Any suggestions? – User892313 Apr 21 '15 at 15:50
  • Can you `ping` the host where you are trying to connect to? Additionally, try to do a `telnet` to that `host:port` – x80486 Apr 21 '15 at 15:55
  • Sorry, I'm really green when it comes to network stuff. I tried to open cmd and type ping 192.168.0.102:1527. It says it's not found, the same if i change the ipv4 adress with the ip adress. Does that mean it's not able to connect, or did i get the command wrong? I also tried puttytel for your other suggestion, trying to connect to ipadress:port, and it says the connection is refused. So i suppose i should open port 1527 somehow? – User892313 Apr 21 '15 at 16:27
  • `ping` works with the hostname only; for `telnet` you should do: `telnet your_host port` – x80486 Apr 21 '15 at 17:32
  • telnet is not recognized by windows 8.1, and what would the hostname be? all i have is a ip and port – User892313 Apr 21 '15 at 18:17
  • Indeed, not sure why `'telnet` is not available in Windows...use PuTTY. But, to your problem, you need to know if there is something running and listening in `` or `` and `` that you want to connect and do a JDBC session; that's why using `telnet` is the best way. On the other hand, to know the hostname of the machine you are running you can type `hostname` – x80486 Apr 21 '15 at 18:27
0

You need to open the port 1527 on your router. And you can try this answer https://stackoverflow.com/a/12176840/2746009

Community
  • 1
  • 1
enrico-dev
  • 155
  • 4
  • 12
0

So, i will recommend you to see the firewall settings, if firewall is not blocking the way or you can give a try to communicate to another port. If both of these things didn't work, let me know, how far it takes before spitting this error out. Also, in command prompt, try ping machineIP and see if it's sending and receiving data

  • I tried opening the port both in the firewall and on the webpage you reach when typing your ip in the brower. I've tried several different web services that check if the port is open, and they all say it's still closed. I can't figure out what i'm doing wrong. I also tried disabling the firewall for a moment with no luck. – User892313 Apr 21 '15 at 17:15
0

I was doing the same configuration and after spending some hours I found the solution: http://db.apache.org/derby/docs/10.2/adminguide/derbyadmin.pdf

Page 34:

By default, the Derby Network Server will only listen on the localhost (...)

One solution is to create a [derby.properties] file with the following content: derby.drda.host=0.0.0.0

The place where you save the properties file may vary:

- in one machine for me it was directly under 'javadb', sibling of 'bin', 'lib', etc

- at my 2nd machine it was under the 'bin' directory, sibling of *.bat files.

To verify if your properties is being read (it doesn't exist at first, Derby doc explicitly tells that it won't create it for you), is to add this property as well: derby.stream.error.file=derbyNewLog.log

If you execute bin/startNetworkServer it will create the new log file in case your properties is correctly being read.

After you confirm that your new properties file is being read, you can use the bin/ij tool to execute connect statements to your DB (both local and remote). This is how I could verify it quickly (my db name is 'differentRequestsAndPerformance'):

c:\glassfish4\javadb\bin>ij
ij version 10.10
ij> connect 'jdbc:derby://localhost:1527/differentRequestsAndPerformance';
ij> show tables;
TABLE_SCHEM         |TABLE_NAME                    |REMARKS
------------------------------------------------------------------------
SYS                 |SYSALIASES                    |
(...)
ij> disconnect;
  >> this 'connect' with localhost is expected to work always - you can append ';create=true' to the DB name in case it doesn't exist already; now change it to your remote ip (I'm assuming you previously confirmed with 'ping' command that you actually can see the server remote machine, otherwise it's a network problem, not a Derby problem)

ij> connect 'jdbc:derby://192.168.1.14:1527/differentRequestsAndPerformance';
ij> show tables;
TABLE_SCHEM         |TABLE_NAME                    |REMARKS
------------------------------------------------------------------------
SYS                 |SYSALIASES                    |
(...)
ij> disconnect;

One additional comment: I'm not sure how much the 0.0.0.0 setting will open your machine to malicious software because I only wanted to verify my code and I disabled it right after I was satisfied. More research on this is required in case you want to use this for real programs.

In case your 'ij' tool complains about some driver, add the javadb/lib directory to the CLASSPATH system variable.

Another thing (obvious but better safe than sorry): this configuration must be set at the remote db (where your requests will arrive), in case like me you have 2 machines both with the database running.