Why does the local user on a network PC not have access to ODBC connections?

A user does not need administrative privileges to create an ODBC DSN. A user can create a user DSN, which is normally sufficent and the way to go.
Otherwise you need to create a system DSN as administrator.

Thank you Ste5an.  I tried creating a User DSN and had the same failure.

If you create a user DSN , this DSN will be available just for you . It will be not visible for other users. As ste5an pointed you can create System DSN and the other users will be able to use it. You can also change the report to use OLEDB  instead of ODBC and then you do not have to deal with DSNs

Well, then the question is: What error messages do you get?

btw, does the DSN work?

Are you creating a 32 or 64 bit ODBC connection.  Crystal (at least through CR2013) requires a 32-bit database connection.

mlmcc

Thanks all.  I don't have the error and will get back with the user to get it.  I'm using 32bit ODBC.  I forgot to mention that the users with this problem are logging via RDP.   It shouldn't be different, in my experience.  The DSN does not work.

As has already been mentioned, the type of DSN is important.  Make sure it's a system DSN.

Also the 32 vs 64 bit is important.   You want to make sure you use the right ODBC applet tool.   For 32 bit, that is found here:

%windir%\SysWOW64\odbcad32.exe.

The one you get from the control panel is the 64 bit version.   Because of backwards compatibility issues, what the system sees depends on the tool you use and the type of DSN.   You can read more about it here:

ODBC Administrator tool displays both the 32-bit and the 64-bit user DSNs in a 64-bit version of Windows
https://support.microsoft.com/en-us/kb/942976

and when you create the DSN, it's a good idea to suffix it with either _32 or _64.  That helps figure it out when things go wrong.

Jim.

Thank you Jim.  I am familiar with the  32 vs 64 bit issue and used the odbcad32.exe.  I also tried setting the connection up as a user and as system.  This issue is on a clients network.  I will connect with them tomorrow to run through the process again and capture all details.

Thanks to all.

The DSN does not work.

Also, "The report fails and indicates no ODBC connection exists." And "...had the same failure."

But what is the error? What messages show up? What exactly is reporting the problem? (What version of the product?) What platform is it running on? And what should it be connecting to?

Apologies for the extended inactivity on this question.  I was away from the location where this problem exists.  In answer to questions posted above I am using the 32 bit ODBC tool and CAN create a User DSN.  When I attempt to run the report I get  Crystal login prompt.  Its not an error message per se but the this report configured I should not see the prompt.  The SQL Server user set in the ODBC connection is a read only and the password is null.   I've done this in the past and it has always worked.   Just not this time.  I'm convinced that there is something in the users rights causing this problem.   I test the report on a users PC who I know has elevated privileges and it works.  I've asked the network administrator  help and m waiting on them.  Thanks to all.

The network administrator where this issue exists has not assisted as I've asked so I have no new information on the problem.

How is the database setup for logon?
Does it use Windows AD?

Crystal does NOT save the user name or the password for the database.

mlmcc

The SQL Server database uses SQL Server Authentication.  I am unfamiliar with Windows AD.  I know Crystal does not save the user name or password.   For a number of years now I've been deploying custom Crystal reports inside another application (meaning that the application has a feature allowing me to add a custom report to a menu.  The application uses old Crystal 8.5, hence my choice of 8.5 for the custom report) and have the customs utilize either a  User or System DSN that points to a specific SQL Server Login with read only rights to the database and a null password.  When the user runs the report from inside the application it uses the ODBC connection on the PC that points to the database.  At the client location there is a user with elevated rights who can run the report via his RDP login.  The two users who cannot run the report because of the ODBC setup issues do not have elevated rights.

Make sure they have permissions to the ODBC connection.

So some users can run the report and some cannot?

Is this report using a different ODBC connection from the others?

mlmcc

The security setup for the clients who cannot run the report is locked down and prevents them from being able to create and ODBC connection of any type.  I am certain this is the issue and have related this to the network administrator.