Accpac 5.6 Error: Error occurred when activating Sage Accpac Data Source 1

[planetbluau]

Environment:
[ul]
[li]Accpac 5.6 PU1[/li]
[li]SQL 2005[/li]
[li]Accpac Installed on SBS 2003[/li]
[li]Users connect via Terminal Server 2003 that has WSSetup Installed[/li]
[/ul]

This installation has been working for over two (or is it three) years now without issue. Now users are getting the error Error occurred when activating Sage Accpac Data Source whenever they open up any module. I am assuming it is a permissions error because, if the user is in the domain POWER USERS group, they do not get the error. As a temporary work-around, I have put the users in this group, however this is not an ideal solution, and afterall, for years they have been operation without being in the POWER USERS group.

I have searched this forum, Sage forum etc. for solutions. Thusfar I have tried this:
[ul]
[li][/li]
[li]Remove and reinstall WSSetup[/li]
[li]Checked paths are ok[/li]
[li]Checked permissions on path to server RUNTIME folder[/li]
[li]Remove and reinstall MSXML 4 SP2[/li]
[li]Deleted and re-created ODBC DSN[/li]
[/ul]

I am startint to run out of ideas. There have been comments about data corruption, however everything works fine if I put the user into the POWER USERS group as mentioned. So I figure it has to be permission related. But what?

Any ideas please that may lead to a resolution would be appreciated.

Regards,
Rodney

 

[Jay Converse]

Run ..\RUNTIME\REGACC.EXE as an administrator.

 

[planetbluau]

Thank you Tuba2007,

I should have included that in the list of things I have done. Sadly, it did not rectify the situation.

Regards,
Rodney

 

[Jay Converse]

So, what got installed recently? Things like this don't break randomly.

 

[planetbluau]

Exactly. Apparently another admin installed an update to a local (Australian) program (nothing to do with Accpac) on the TS. At present, I am unable to uninstall it due to it being in use right now. I am suspect of what 'additional updated' it may have done to other data access things. Although, it does not use the SQL server at all. In fact it does not use any ODBC DSN's. But it is a factor.

What has me baffled is that it works fine if the user is a POWER USER. Hence, permissions???

 

[Jay Converse]

Try re-installing System Manager, not just WSSETUP. And if System Manager was never installed on the TS, go ahead and do it. Plus the latest PU, of course.

 

[planetbluau]

OK, Tried the install of SM on the Terminal Server (it has never been installed there before) however this did not help either.

Interestingly, if the NON-Power users logs into the SBS server (which has the SQL and the Accpac install) then they do not get the error msg. But as soon as the same user tries on the TS, they get the the error message. Only Domain Power Users (on the TS) do not receive the error!

Normal (non Domain Power Users) can login, open accpac, see the modules, but as soon as they go to open ANY module (even a report) they get this error. I have run DB SPY but cannot identify any issue.

Arrggh!

I have now done a reinstall of Accpac on the SBS, recreated (again) all ODBC connections and still no joy. There is just something wierd happening between the TS and SBS when a user is not a POWER or ADMINISTRATIVE user.

Thanks for your continued input though!

R

 

[planetbluau]

My gut feeling (and maybe way off here) is that that some permission problem is stopping the temp write of some dataset at the TS end. But can't figure what could be different at the TS compared with the SBS as the user account is the same!

 

[Jay Converse]

I don't think this is a data or ODBC problem. But, try adding a User DSN with the same name as the System DSN.

 

[planetbluau]

Ok tried that (and removed the SYSTEM one so that it would have to use the USER one) and same error.

 

[ramam1]

File system permissions for the accpac program folder?

 

[planetbluau]

Thanks Raman1, however I have checked all permissions for the Accpac program and shared data paths/folders and the non-admin user has full rights. I have tested it by reading and writing to the folder as well as confirming folder permissions.

 

[DjangMan]

Download and run ProcessMonitor. It records a lot of activity but it might help sort out where the permissions issue is hitting.

Also - have you checked the permissions on the share (vs. the folder)?

 

[planetbluau]

Thank you to all who have commented on this issue. We finally got to the bottom of the issue today. It was a rather odd set of circumstances that led to the error in Accpac, but if it helps others track down similar things, all good.

As mentioned in a previous post, another admin (non-skilled) had installed an update to a payroll program (Fox Pro Based). Updates for this program normally affect only the FoxPro data tables with new tax and payroll law data, but this update aslo changed/updated some DLL components like MSXML core etc. Even though we did a reinstall of that component earlier, it did not rectify the issue. On investigation of the INSTALL.LOG of the payroll program, we found that the person installing it had not used normal Terminal Server methods but rather, the install put some DLL components in wierd, personal profile areas. We presume this caused part of the permissions issues when Accpac tried to use those regisitered DLL's. Even though we run REGACC etc. the problem persisted.

The solution was to remove the payroll program completely (Accpac still did not work correctly) then we re-installed the payroll program correctly, and checked that all DLL's went to proper system locations. Once this was done, Accpac could access the required shared DLL's and worked without a problem. We could return all users to non-elevated security status.

As tuba2007 mentioned, "Things like this don't break randomly" and it took us a while to get the full story on what was happening with the payroll program. It was left as the most likely cause. The solution only became evident when we uninstalled AND reinstalled the program correctly.

Hope this thread helps any others who may stumble across a similar situation.

Thanks again,
Rodney