Title: CA ERwin Data Modeler r8.1, r8.2 (or 9.0) ODBC Connectivity Problem - Cannot Access (Grayed-out) Pinned Reports with Windows 7 (ERwin Problem 11477)
Description:
Identification & Diagnosis:
After upgrading to, or installing CA ERwin Data Modeler r8.1 or r8.2 (or r9.0) with Windows 7 (or Vista), pinned reports are not accessible (grayed-out) and ODBC connections fail (error: connection refused).
NOTE: you must have a model open in ERwin to make the reports accessible (not grayed out). If you have a model open in ERwin but the reports are still grayed out, then this article can help you.
These issues all have the above Symptoms and conform to the following:
ERwin Problem #11477
- ERwin is version r8.1 or r8.2 (or r9.0)
- Operating System is Win7 or Vista (32 or 64 bit)
- Only one instance of ERwin is running
- Check Task Manager Processes and make sure there is only one instance of "erwin.exe"
- With a model open, when trying to connect through the Query Tool, there is an ODBC connection error
- The problem does not occur in ERwin r8.0 or ERwin r7.3.
- ERwin performs correctly in all other respects
If your symptoms do not conform to the above, it is probably not the same problem.
Solution:
IMPORTANT!
If you experience this problem with ERwin r9:
Go directly to step 1-d: Grant the user "Create global objects" privilege.
(If that does not resolve the problem another strategy is to set the shortcut that launches r9 ERwin so it runs as Windows XP SP3 compatible).
DO NOT perform any other steps if you have CA ERwin DM r9!
NOTE: The following steps must be followed carefully. Missing one item can cause this solution to fail. If you have followed this document and the problem still occurs, please carefully review each step especially steps 1-c and 1-d.
Resolving the Problem:
IMPORTANT: User must have full administrative privileges in order to perform these steps.
-
Reconfigure Open Access
-
Replace the original copy of "oadm.ini" with a corrected version
Please click here to download the new oadm.ini
The original file has known problems and must be replaced. The "oadm.ini" includes paths that are machine and environment specific. There are two updated versions: one for Win 7/32 (oadm.ini.32) and one for Win7/64 (oadm.ini.64). These files should be correct for default installations in 32 or 64 bit environments respectively.
-
Rename the installed version of "oadm.ini" to "oadm.ini.8.x"
- The default location is: "..\CA\ERwin Data Modeler r8\OpenAccess\oaserver60\cfg\"
- Select the appropriate modified file (either "oadm.ini.32" or "oadm.ini.64") and copy it into that folder
- Rename the modified version by removing the extension (the name should be "oadm.ini")
- These files are configured for default installations, if it is a non-standard environment, or ERwin has been installed to a location other than the default, the updated copy of "oadm.ini" will have to be edited. Those steps are copied below.
- Create New ProgramData Folders:
C:\ProgramData\CA\ERwin Data Modeler\8\ODBC\openaccess - Grant the ERwin user "Full control" in the ERwin ProgramData folder:
C:\ProgramData\CA
Instructions for doing this are copied below. - Grant the user "Create global objects" privilege. That can be done through:
Control Panel->Administrative Tools->Local Security Policy->Security Settings->Local Policies->User Rights
-
Set CA ERwin Data Modeler r8 to run with Compatibility Mode for Windows XP
This may be done with or without reconfiguring OpenAccess (step 1).
- Right-click on any shortcut for CA ERwin Data Modeler r8
- Select "Properties"
- Select the "Compatibility" Tab
- Check the box labeled:
"Run this program in compatibility mode for:" - Select a version of Windows XP in the drop-down list
- Click "OK" to save the changes and close the dialog
NOTE: This needs to be done only once. Once the compatibility mode has been set for an application, it will continue to open in that mode until the setting is changed.
Further information is available at the following link:
http://windows.microsoft.com/en-US/windows-vista/Make-older-programs-run-in-this-version-of-Windows
- Make the user part of the Administrator group on the machine
IMPORTANT: The following should be done only if the above steps did not resolve the problem.
This is to be considered only if the first steps did not resolve the problem. Also, note that this is not considered a true solution, only a temporary work-around until the problem of requiring administrator privileges has been resolved. For some organizations, making users an Administrator-even on a temporary basis-is not allowed. If that is the case, we can suggest that the user either wait for a release that includes a fix, or move back to ERwin r8.0.01 (not r8.0).
APPENDIX: Supporting Information
-
GRANTING FULL CONTROL:
- Login using an admin account
- Open File Explorer
- Navigate to the folder where you are to grant "Full control"
- Right-click the node:

- Choose "Properties"
- Select the tab labeled "Security"
- Click "Edit"
- Select the group that you want to grant "Full control" (in the case "Users").
- Click the "Allow" checkbox under "Full control"
- Click "Apply"

If you get an error it means that your login doesn't have full admin privileges, or there is some other security restrictions in place. You can try without granting "Full control", but first make sure the openaccess folder is completely empty.
- EDITING "oadm.ini":
If the user has a non-standard environment or has installed to an alternate location, the paths in the attached copies of "oadm.ini" must be changed to match the environment.
This is simple to do using any text editor.
Searching for the following string will locate all instances of paths that may require modification:
"C:\Program"
You will find paths that begin:
"C:\ProgramData"
And one of the following:
"C:\Program Files\"
or
"C:\Program Files (x86)\"
Simply edit the beginning of each path to conform to the appropriate location for the user's environment.
NOTE: Rather than use our modified copies of "oadm.ini" you might be tempted to just edit the user's copy. I advise against that because there are many other changes in our versions of "oadm.ini" other than paths and they would have to be found and replicated in the user's version.