04-30-2012 08:54 AM
This is a little difficult to describe.
A large Act Database had to be moved from one server to another because the original server was being decommissioned. The original database used an old version of ACT, had not been maintained, it had many duplicate records that the users wanted to retain. The database was exported, a new database was defined on the new server (the users wanted a couple of additional User fields). The data was imported into the new database. No problems. However, the new database was created on the server’s local drive, which was very small. It should have gone on the corporate storage used by the server (we weren’t aware it existed). The server admin. people insisted it be moved there and they undertook to move it. We would have preferred to back it up and restore it in the new location but.... nerds know best.
What follows is a list of problems that occurred and big question mark;
This is all that I have found that I can tweak. I’m beginning to think that down deep in ACT’s dungeon ACT is dredging up that old path and using it no matter what I tell it to do.
04-30-2012 01:52 PM
If you haven't updated the restored database very much and would rather use the moved copy (125,000 records), the customized layout should be be in the original copy of the Layouts folder - you can copy it to the new moved copy of the database. It would be under the 'databasename-database files/layouts' folder.
To ensure there is no confusion due to the names of the databases, here is an option:
- stop the SQL Server (ACT7) service
- copy (not move or cut) the ADF and ALF files, and the 'database files' folder of the restored database and paste them into a new folder (can be sub-folder of original)
- start the SQL Server (ACT7) service
- rename the file names (ex: add 'New' to the beginning) - ensure that the file names are identical (do not change the extensions)
- open this new copy of the database using the ADF
Microsoft SQL has a lock on the database files, that is most likely what causes your incremental backups to fail. It is best to use the ACT! Scheduler to create backups of the database (*.zip) and then have the backup files included in your backup program.
05-01-2012 04:07 AM
05-02-2012 05:25 AM
Thanks. Please refer to the list of what I've attemped. Is there a way to force ACT to go to the database I told it to go to or as a minimum to tell me why it did not go there?
05-02-2012 06:10 AM
I was recommending the copy of the database files and renaming them in case your existing copies of the database had the same file names; that could have been causing the confusion opening the database. You can reset your ACT! preferences to make it 'forget' which database was last used - this may resolve the issue, here is an article with instructions: KB Article 14770
I recommend using the section titled: "Alternate Method: Manually Rebuilding Preferences".