What is the current tool for mapping Unidata files for ODBC?

Kevin,

I still use VSG - part of the U2 Clients package,

Regards

JJ

What is the trick for getting ODBC to work?

I setup the 64-bit ODBC driver to connect to Unidata 8.2.1.  I configured uci.config to allow access to the system I want to access with ODBC.  I configured an ODBC connection in the 64-bit ODBC driver tool in Windows.   When I press the “Test Connection” button, I get this:

[Rocket U2][U2ODBC][0302086]Error ID: 71 Severity: ERROR
Facility: DBCAPERR - The UniRPC daemon is not running. You
must start the deamon before using U2 ODBC.

If the ps in Linux is to be trusted, unirpcd is running.  If netstat/ss are to be trusted, it’s listening on port 31438.  I can access this port with telnet so it doesn’t appear to be restricted by a firewall.

The ODBC configuration says the uci.config file is running from C:\U2\UniDK\U2ODBC_64bit\Config\uci.config.

Not sure what I’m doing wrong.

I’d start with the 64-bit ODBC driver, 64-bit DSN and the 64-bit tester in a copy of the ‘demo’ account or HS.SALES. Remember on UniVerse you need to enable ODBC access using HS.ADMIN, VSG is UniData only.

The usual issues beyond these are firewall (port 31438) or O/S permissions for the user ID uses - try a local machine administrator at firsr. ODBC/RPC logging (client and server side) can also help.

Regards

JJ

Kevin,

This article might also be useful: https://my.rocketsoftware.com/RocketCommunity/s/article/Failure-to-connect-to-UniVerse-or-UniData-using-an-ODBC-data-source-1478610326132

Regards

JJ

Yes, that is excellent.   It seems to be more Universe centered than Unidata, but it’s excellent nonetheless.  Thank you for sharing.   Still can’t get a connection from this Windows 11 system, says that UniRPC is not running but it does in fact seem to be running based on ps and netstat.

Kevin,

Ignore ODBC - just try loadong the DOS/Windows telnet client on the relevant client PC and run

telnet <server IP address> 31438  at DOS

If this connects but if you use the host name it fails then there’;s a DNS issue.

Do you connect (there will not be a visble response - just a successful connection).?

If not then firewall…… though as a last step try this direc from the server console as an administrator “Run As” on Windows, ‘su’ on Unix). If you can connect from the server console bit not froma  client PC then the network security settings need to be looked at as well as server firewall settings as network routers can block.

If yes then I suspect a  server-side permissions failure - turn on RPC logging.

Regards

JJ

The port is open and accessible via telnet.  I was able to finally get a successful connection but I do not know why.  But it’s connecting now.