Shoddy Programming

I was held up Friday trying to track down why, oh why, an image backup of a server that had one job, to run a fairly recent version of act, kept failing. That brought me to this post in the help forums: Installation of ACT! reproducibly destroys ability to make Image Backups due to VSS errors. Buried in the thread, after the company rep on the forum had basically said "not our problem, the issue is with SQL, we didn't write that" is this golden bit.

I entirely agree with your assessment, based on my all-too recent experience, from which I am still reeling:

1. My backups were running perfectly for months before Act was installed; they failed the day I installed Act.
2. I did not install the SQL Server VSS Writer service or choose the account that it would run under. This was all done automatically by the Act setup process with no options or even caveats mentioned in the documentation.
3. It was not the SQL Server VSS Writer service that needed to have authentication information adjusted; it was the Act 7 SQL instance that contained the conflicting Local System authentication by default.
4. Even if, as @Elise suggested, I follow the guidance at the link here: http://kb.act.com/app/answers/detail/a_id/19211, I would have the same problem, since the default installation configured the Act SQL instance in such a way that it was guaranteed to break my VSS-based backups, regardless of whether I was also using the Act Scheduler or not.

So, try to tell me how, from my perspective as an information systems professional, the backup failure is not only Act-related, but Act-induced. Perhaps there is another vendor out there that might provide, without any helpful documentation, default settings that break one's VSS-based backups, but I have no proof of that because Act is the only one I have seen. I still have very little clue as to why this is an issue, since I am not a SQL expert nor a Windows security expert. But, then, I should not have to be, or become, a SQL expert just to integrate Act as one small part of an organization having many more pre-existing applications. In fact, SwiftPage is the development, marketing, and sales organization for Act, which runs on SQL. In my experience with software vendors over the last 20 years, it has always been incumbent on vendors to ensure that 1) they have experts on staff for not only the programming languages, but also for the database platforms for which they choose to develop and 2) they create common environments for testing beside the development team's computers in the company's own network.

Unfortunately, this is not the first time Act has come into focus for me this way. I thought I had seen the end of the old, sloppy ways of approaching things the last time I dealt with Act in a corporate environment perhaps seven years ago....

I've had to deal with Act! in the past, in seeral company's hands - including Sage at one time - and even before it shifted to something like a real database (MS SQL Express), it was a flaky and cantankerous application the second you expected to share data with anyone. The guys at swiftpage have stopped providing any form of uninstall utility, but instead provide a long and onerous instruction page full of multiple sets of registry item removals and files to track down.

This would be less irritating of the Sage-era Act! didn't have that utility still available.

It still takes a special chutzpah to absolve oneself of issues that one causes by their own choices. As the forum member points out, MSSQL may not be software made by SwiftPage, but the error/bug/etc. is one of integration and configuration by SwiftPage. Not one inherent to SQL.