Connect to Pervasive database remotely

I'm trying to connect to a Pervasive database remotely and I have done everything needed to connect but it does not work on the remote server. Port is open on the firewall and I can telnet to the 1583 port from the remote server and also see the packets from the remote server.

On the remote server, I'm using PCC to connect to the remote computer.

Here is the configuration of the database server

LVL 1
GerhardpetAsked:
Who is Participating?
 
Bill BachPresidentCommented:
OK.  Now we have a better picture of what is going on.  Since we know the server engine is listening and communicating normally on the LAN, it should ALSO respond to the inbound calls, if forwarding is correct.

So, the first thing to do is make sure that port forwarding is working.  You can use the command "TELNET 184.68.xxx.xxx 1583" to test the port forward process.  You should get a black screen with no error message if it is working.  (There is no telnet interface, so you can simply close the command prompt if it connects.)  I would first recommend running this on the LAN, so you can see what success looks like.  Then, run this from the DMZ, or from the public 'Net, or whereever else you need to run it from.  Note that 1583 is the TCP port for SRDE communications, so you must provide this number at the end of the command for it to work correctly.

Once you have TELNET working, then SQL queries (via the ODBC connection) should also work.  Note, though, that the calls to obtain the Named Database list are NOT done with the SRDE interface, but rather they use the UAPI interface, communicating over TCP port 3351 (like Btrieve).  If you are hoping to setup the ODBC connection via the GUI, then you may need to ALSO forward TCP port 3351 in addition to 1583, at least for a short time.  Once you have set up the DSN, you can disable the 3351 forwarding.  If you don't want to poke the second hole, you can simply set up the ODBC DSN manually with RegEdit.  Set up a DSN on the local segment first to see what the registry settings need to look like, and then make those same settings on the remote machine.
1
 
Bill BachPresidentCommented:
First things first:  Using the PCC, can you connect to the server from the Client?  If you've not done so yet, right-click the Engines and select Add/Server.  Enter the server name, and it should connect.  Now, verify that you can open the server and see the named databases.

Second, what kind of connection are you attempting?  DSN? DBName? DSN-less?  If possible, provide your complete connection string.  Also, if possible, provide a screenshot of both the PCC showing the named databases on the server.  If using a local DSN, provide a screenshot of the ODBC Administrator showing the DSN you have configured.
0
 
GerhardpetAuthor Commented:
Bill,
Yes on the local network I can connect from a client (windows 7) using PCC and can see the named database. Same on the server itself, I can see databases and tables.

I'm attempting to use DNS. So far all I have attempted is connect from the remote server using PCC to the local server.

Here is the screenshot
databases.jpg
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
Bill BachPresidentCommented:
The server is working fine, then, as is the PSQL Client.

Is your odbc application 32 bit or 64 bit?
Is the dsn that you created 32 bit or 64 bit?
Can you post the screenshot of the dsn?
0
 
GerhardpetAuthor Commented:
32 bit. On the remote server, I'm trying to create a DNS and when I enter the IP of the server with the PSQL database I get the following. I'm not sure I'm doing is the correct way.

Here is the screenshot where I'm trying to create a DNS to the remote server when I click get DNS List
 dns.jpg
0
 
Bill BachPresidentCommented:
Since the pcc is working, stick with the server name, not the ip address.  Clearly, WIN-SQL is working. Why are you trying to use the ip here?
0
 
GerhardpetAuthor Commented:
The WIN-SQL is the local server name. On the remote server, the WIN-SQL does not resolve to the database server. The last screenshot is on the remote server

In the remote server PCC is not works as I mentioned before
0
 
Bill BachPresidentCommented:
You have me confused, now.  In your message above, you state: "Yes on the local network I can connect from a client (windows 7) using PCC and can see the named database."  Then, you say "In the remote server PCC is not works".  So, is the PCC working or NOT working?

While you are checking that, check for valid name resolution.  On the client PC in a command prompt, run "PING WIN-SQL" and check that the server responds AND that it is the correct IP address for the server.
0
 
GerhardpetAuthor Commented:
By remote server, I mean over the WAN

I have the local server with Pervasive and the database which is server A. I have the remote server B from where I want to connect to the server A (WAN).

When I test PCC on server A it works. Also when using PCC on the local network using a Windows 7 computer to server A it works

When using PCC from server B (remote over WAN) to server A (local) it does not work.

Yes, there is name resolution on the local network.

On server B there is no name resolution to server A and that is why I'm trying to use public IP with port forwards.
0
 
GerhardpetAuthor Commented:
In my first post, I did already mention that I can telnet from remote (WAN) to the local server on port 1583 so port forward is working.

I will try the rest
0
 
GerhardpetAuthor Commented:
That was it! All I did is forward port 3351 and it works! Thanks Bill for your help.
0
 
GerhardpetAuthor Commented:
Oops forgot to close the question
0
 
Bill BachPresidentCommented:
Port 3351 was needed.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.