"Get DSN List" is blank with setting up ODBC connection?

[Apollo6]

I have Pervasive.SQL v8 setup on a W2K Server. I have an application installed and pervasive database setup. The application is working correctly, it pulls data from the database. The application has a thin client that is loaded onto workstations. I've loaded the thin client on a workstation and it too is working correctly, it pulls data from the database that is on the server.

I am now attempting to setup an ODBC link that I can link the tables into an Access'97 database on a workstation. I go into the ODBC Administrator and select System DSN, select Add, select Pervasive ODBC Client Interface from list of drivers. I put in the data source name, the server IP address, and select 'Try TCPIP Only'. When I click on the "Get DSN List", it is blank. Regardless of which transport option selected, the dropdown is still blank.

Am I forgetting to do something on the server that allows a workstation to see the DSN list from the server? Any suggestions are greatly appreciated.

 

[mirtheil]

Have you set up a "Pervasive ODBC Engine Interface" DSN at the server? It not, that's what you'll need to do. THen you can access that Engine DSN from the client (using the Client DSN).


Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician
Custom VB and Btrieve development.

http://www.mirtheil.com

 

[Apollo6]

Yes, the Pervasive ODBC Engine Interface is created on the server. I can see it in the Pervasive Control Center. Basically what I have is the application and database on a production server (NT), currently being used, currently having working ODBC connections as well. We have a new server (W2K), that I installed the application and pervasive onto, we are migrating to the new server. All is working fine with the exception of making an ODBC link from a workstation.

The application is called ACCPAC, an accounting package. I don't think it is a port issue on the new server because the thin client, installed on the workstations is making the connection and pulling data from the new server. Could it be something else on the new server itself that is prevent me from seeing the DSN list on the workstations?

Thanks again

 

[mirtheil]

The only thing that would keep a client from seeing a DSN that's defined on the server would be network communication issues or the DSN isn't defined on the server.
When you use the PCC, to see the database, are you at the server or client? What happens if you try it from the other one (if at server, try at client. if at client, try at server)?
Is the Engine DSN on the server defined as a "System" DSN in the ODBC Administrator?


Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician
Custom VB and Btrieve development.

http://www.mirtheil.com

 

[Apollo6]

When using the PCC, I am on the server and can see the database. When using the PCC on the workstation, I don't see the database. As for the ODBC Administrator on the server, should there be an entry in the "System" DSN? There currently is not and when I try adding a system DSN, it tells me that one already exist for the database I am trying to add.?.?.

 

[noodles1]

Keep in mind that Pervasive uses different TCP/IP port numbers between the ODBC and the Transactional interface. The defaults for ODBC is port 1583. This can be changed. The port for the Transactional i/f is 3351 from memory and cannot be changed. However, I don't think this is your problem here.

Can you see the server database in PCC from the workstation? Remember that you must register the server "engine" in the client PCC first?

 

[Apollo6]

noodles1-

Workstations currently pointed at the old server do not have the server engine registered in the client PCC. However, you can still see the databases (Client) on the workstation and they have no issue with creating an ODBC connection.

What I have been able to figure out is that I can hack the workstation registry and manually add the ODBC connection for the database(s) on the new server and it works. I can't explain why it works but it works.

I would still like to find out specifically why or what I am doing wrong because although I have found a workaround, it shouldn't have to be done that way.

Thanks for the input.