I tried copying the templates to another folder; renaming them, delting the oringinals; and then copying the renamed files back into the folder - no luck.
I tried deleting the files from the suplemental folder on the remote and then copying the files from the server into the RDB manually. A soon as I syn, I get duplicates again with date/time ammended to the file names.
My DB was created in 2010 Premium and has been upgraded to 2011 and now 2012.
My gut says this is a future hotfix item and I am wasting my time trying to fix it.
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!
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.
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.
