450
Trial balances for a specific calendar year errors out for all users except for Sysadmin. They are using Windows Authentication.
When tested on the server for sysadmin it runs without issues for 2020, when run by any users on their workstations it errors out with the following Crystal Reports error.
Has anyone else seen this? I ran Synchronize Ownership once, but may do it again.
Have you checked for records in RPTRuntime and RPTCompany that shouldn't be there? It also possible that there is a corrupt record in AcctHist. Have you done a check on the FiscYr field there?
Thanks for the thoughts, we have tried all of that. Have Microsoft support involved but not coming up with any resolution. It works on the application server regardless of which user runs it. Does not work on any workstation regardless of which user. Put a select on the report and it works, try to pull the full report and it fails. Have tried standard report and same result.
DNS doesn't seem to be a likely cause, the report is pulling from the same tables whether pulling from just the current year or previous years. An account with local admin rights would be needed to remove a System DSN from a workstation. You may try leaving a profiler trace running while a non-admin user runs the report, see if they receive an error. Also make sure the standard report is being used, not a customized version, in case incorrect logic was used by a customized report.
Well this has come up again. Deleted the User DSN's and it did not resolve the problem.
Very odd!
Do the System DSN's get used when reports are run without any templates or sorts or selects?
When we deleted the User DSN's we could do without issue, when we tried to click on the System DSN tab we could not and got an access rights error.
Wondering if network rights is the cause of all of this. Just very odd that it pops up out of the blue.
Since Windows Authentication is used, would synchronizing ownership impact this?
On a user’s workstation have them refresh the DSNs—click Start and type: ODBC. Then open ODBC Data Sources 32 bit. On the User DSN tab remove all of the SL database Data Sources. They also should check the System DSN tab and remove any SL database sources there.
Then have the user test the report. If the error no longer occurs do the same for the on the other workstations.
You might try this approach
On a user’s workstation have them refresh the DSNs—click Start and type: ODBC. Then open ODBC Data Sources 32 bit. On the User DSN tab remove all of the SL database Data Sources. They also should check the System DSN tab and remove any SL database sources there.
Then have the user test the report. If the error no longer occurs do the same for the on the other workstations.
Thanks!
Jana MacDonald
Dear Laura,
It looks like a permissions issue , Can a regular user run it on the server? It could be odbc on their workstations?
Have you tried putting a user in the administrators group to run it?
It doesn't seem to make sense that you can run it for one fiscal year and not others. Are you running the standard report and not a custom report?
If you are on a supported version you can open a case with support. Supported versions are 2015 and 2018.
Best Regards,
Jana MacDonald
#1
André Arnaud de Cal...
292,516
Super User 2025 Season 1
#2
Martin Dráb
231,432
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (
