11-06-2011 06:59 PM
ACT 2012 Premium
Publisher Machine: Windows Server 2003
Remote Machine: Windows 7 Pro
My gut says this is a future hotfix item and I am wasting my time trying to fix it.
But any suggestions?
11-13-2011 04:56 AM
11-14-2011 09:06 AM
11-14-2011 10:02 AM - edited 11-14-2011 10:03 AM
It only became evident after upgrading to 2011 and then to 2012.
We had been using 2010 and then bought the 2012 upgrade prior to it's release date, The ACT CSR gave us licence key to use 2011 in the meantime, which is why we upgraded twice in such a short period of time. Bad decision in hindsight. Actually, upgrading from 2010 was a bad decision in hindsight - with all the issues it has created for us.
Apparently there is a 2011/2012 update in the works, which is scheduled to be released in a few weeks time. I suspect this will address this issue, along with my other sync issue - hopefully!
Click here to: View the Reply.
01-03-2012 04:40 AM
Time for a bit of thread necromancy.
Did you get a solution to this issue? We are also seeing this problem on fully up-to-date (as of 23/12/11) copies of ACT 2012, with brand new remote databases, etc. We seemed to have resolved it at one point (deleted all the templates, created new remote databases, created new templates by copying the content from the old templates), but it has now returned.
The client we're seeing this with is about five minutes from dropping ACT completely with all the time ACT 2012 has cost them.
01-03-2012 06:43 AM
Note: Effective 6/1/13, Sage no longers provides support for the Act! software. This is now provided by Swiftpage.
01-03-2012 06:45 AM
Welcome to the Sage ACT! Online Community!
Performing the following should resolve this issue:
1. Have all remotes complete a synchronization.
2. Stop using the existing remotes (no further updates applied to them).
3. Create a backup of the main database (File > Backup > Database)
4. Restore the backup file to a new database name (File > Restore > Database > Restore As)
5. Update all attachments to the desired name (remove date/time stamps).
6. Create a new remote database > restore it on a workstation and test synchronization to ensure files are not renamed.
7. If file names remain intact, create new remotes to replace the remaining remotes.
The fix here is that the main database is recreated with no pre-existing remote sync log information. It is that pre-existing information that appears to be causing the continued renaming.