It is not a SafeCom problem if the person installing SafeCom accidently chose to install the SQL database on

the wrong partition. But in case e.g. the database has outgrown the drive, and needs to be moved to
another drive, the following process can be used. This process it not to be used if the SafeCom server or
SQL database is clustered.

P.S. As this is a change in the SQL Management studio, a database can only be moved to a drive that is seen
as local to the SQL Management studio. It is advisable to have available the encrypted password for the
safecom sql user owning the 4 SafeCom databases. If Windows authentication is used instead of SafeCom
authentication, then the login and password for the Windows user currently being used to run the SafeCom
service on the master server, needs to be known.
As the physical files are moved to a new location, then you need to ensure that the Windows accounts with
permissions to the folder currently holding the SafeCom database files (scccore.mdf, sccore.ldf,
scevent.mdf, scevent.ldf, scpurse.mdf, scevent.ldf, sctrackingw.mdf, sctrackingw.ldf) is granted the same
permissions on the new folder.

In the following it is assumed that it is the SafeCom database files for the master sql server that is to be
moved.
If it is the sql database files for a slave database that is to be moved then skip to step 25.

Before the sccore database files can be moved, the database can not be setup for replication.
This implies that the Distribution and Replication for the SQL instance will have to be temporary
disabled. Replication and Distribution will be disabled for all databases, not just SafeCom, on the SQL
instance holding the SafeCom databases. So make sure to have the SQL DBA agree on this before
continuing.
When the move has been done, we will use Repair Replication from SafeCom Administrator to
automatically setup replication to the slave databases again. Replication to other non-SafeCom databases
will have to be setup manually as per SQL DBA instructions.

1. Use SQL Mangement Studio to take a full backup of the 4 SafeCom databases, sccore, scevent, scpurse,
sctracking.

2. The SafeCom database files (scccore.mdf, sccore.ldf, scevent.mdf, scevent.ldf, scpurse.mdf, scevent.ldf,
sctrackingw.mdf, sctrackingw.ldf) needs to be located on the Sql server. Default file location is often:
C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA
When found, then take properties for the folder. Note down the rights as seen in the Security tab.

3. Stop the SafeCom service and the print spooler service on the master server. If the server is also running
other SafeCom services, then stop those also.

4. On the master sql server, stop the SQL Agent service for the SQL instance holding the SafeCom
databases. This will ensure that no replication attempt is made while the move is being performed.

5. Start up Microsoft SQL Management studio, and connect to the master sql database. It is recommended
to be logged in as the safecom sql user (or if the installation is running with windows authentication, be
logged in as the windows user setup to run the SafeCom service)
6. You will now need to disable Distribution and Replication for this entire SQL instance.
This is done by Right Clicking “Replication” and choosing “Disable publishing and Distribution”
A Wizard is displayed. Follow the Wizard and say yes to Disable publishing on this server.
Complete the wizard. This change will affect any sql databases in this SQL instance. Not just the SafeCom
databases
Please note that eventual non-SafeCom databases residing in the same SQL instance that was setup for
replication, will need to be setup manually for replication at a later state.

6A. If for some reason you are unable to Disable Publishing and Distribution, then the sql script
“remove_db_replication.sql” when run from a querry analyser, will force Replication to be stopped.

7. Now please make another SQL backup of the 4 SafeCom Databases.

The reason for the extra backup is that, you will then have a backup with replication, and one without. So in
case somethings goes wrong, you will need to restore the SafeCom backup that corresponds to the current
replication status of the SQL server. (in other words, if Replication and Distribution is enabled or not at the
time of database restore)

8. In SQL management studio, one by one, right click the 4 safecom databases (sccore, scevent, scpurse,
sctracking) and chose Tasks, Take Offline (close the confirmation box). Please note that this sql task can
take some time to complete.
Should you get an error, or in case the process seems to newer complete. Then try disconnecting the
connection to the SafeCom SQL instance. Close down SQL Management Studio, and reconnect again. It
should then be possible to bring the database offline. (Or it might in the meantime have changed to the
offline state)

9. In SQL management studio, one by one, right click the 4 SafeCom databases (sccore, scevent, scpurse,
sctracking) and chose Tasks, Detach (Tick the “Drop connections” box, and hit OK.)

10. Now it is time to move the physical files ((scccore.mdf, sccore.ldf, scevent.mdf, scevent.ldf,
scpurse.mdf, scevent.ldf, sctrackingw.mdf, sctrackingw.ldf)) to the new folder. Remember that the folder
must be on a drive that is visible from Sql Management studio. This means that the drive used must be seen
as a local drive. Network drives can not be used.

11. After moving the SafeCom files to the new location, make sure that the folder holding the SafeCom files
are assigned same rights as the old folder has. See step 2.

12. In SQL Management studio, (still logged in as the same user), right click “Databases” and choose
“Attach”
Click the Add button, and browse to the folder you copied the 8 SafeCom database files to.
Highlight the sccore.mdf file and hit the OK button.
Click the OK button to add in the database.

13. Repeat step 12. and one by one add in the scevent.mdf, scpurse.mdf and sctrackingw.mdf database.

14. One by one, rightclick the added SafeCom databases and take properties. In the General tab, verify that
the correct user is listed as owner for the database.
(15). If the safecom sql user was intended to be the owner of the databases, but it turns out not to be the
case, then you can run the sql script scChangeOwner.sql as a querry in SQL management studio. The file is
found in the Safecom installation folder. Running the script will force the safecom SQL user to become
owner of the 4 SafeCom databases.

16. Close the SQL Management Studio. On the Master server start the SafeCom service, the Print spooler
service, and eventual other services you closed down in step. 3

17. Open up SafeCom Administrator, and verify that you can login to the SafeCom Database.

18. Now it is time to start up the SQL Agent on the Master SQL server. To allow Master sql server to
replicate changes to slave databases.

19. In SafeCom Administrator, Right click a slave server, and choose “Repair Replication”
This will enable Publising and Distribution again, and setup replication to that slave. This could take several
minutes as the Master SQL instance has to enable Publishing and Distribution and setup replication from
scratch.
(SafeCom G3 versions older than G3 420*06, does not have the “Repair Replication” option in SafeCom
Administrator. A way to force replication to be setup/repaired, is to open Server Properties for the Slave
server in SafeCom Administrator, and on the Tracking tab toggle Online Tracking/Offline Tracking. Press the
“Apply” button. Wait 2 minutes, then change the setting back to what it was, and press the Apply button
again)

20. For each slave right click and choose “Repair Replication”, in order to setup replication for that slave.
(For SafeCom G3 versions older then G3 420*06, repeat the special procedure in step 19. for each slave)

21. In SQL Management Studio on the Master SQL server, Click “Replication” and press F5 for refresh.
When you expand “Replication”, “local publication”, you should now be able to see “sccore sccore [Trans]”
which is the SafeCom Replication setup and when you expand further, there should be an entry inside per
slave server.

22. If you were only moving database files on the Master SQL server, then you are done now.

Special Case: Moving sql databases on a slave server

Step 25. Special case: You need to move the SQL database files on a slave server setup for replication.

26. On the Master SQL server, Stop the SQL Agent service for the SQL instance holding the SafeCom
databases. This is to avoid replication attempts to slave servers, while a slave server database is being
worked on.

27. On the Slave server, the 4 SafeCom database files (scccore.mdf, sccore.ldf, scevent.mdf, scevent.ldf,
scpurse.mdf, scevent.ldf, sctrackingw.mdf, sctrackingw.ldf) needs to be located on the Sql server. Default
file location is often:
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SAFECOMEXPRESS\MSSQL\DATA (if Sqlexpress) or
C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA (if full blown SQL)
When found, then take properties for the folder. Note down the rights as seen in the Security tab.

28. On the slave server, stop the SafeCom service and the print spooler service. If the server is also running
other SafeCom services, then stop those also.

29. Start up Microsoft SQL Management studio, and connect to the slave sql database. It is recommended
to be logged in as the safecom sql user (or if the installation is running with windows authentication, be
logged in as the windows user setup to run the SafeCom service). If you do not have SQL management
studio installed on the Slave server, you will need to use e.g. the SQL Management Studio installed on the
Master sql server. If the Master SQL server has an older SQL server version (e.g. SQL 2005) than the
instance installed on the slave server (E.g. SQL 2008R2 Express), then you will need to install the Correct
SQL Management studio on a server or workstation, and connect to the Slave database from there.

30. As the Slave server is setup for replication from the Master sql server you will not be able to detach the
sccore database. You will therefore need to run the sql script “remove_db_replication.sql” against the slave
database, as this is the only way to Disable Publishing and Distribution on the Slave database in case the
SQL Express database is used.

31. In SQL management studio, one by one, right click the 4 safecom databases (sccore, scevent, scpurse,
sctracking) and chose Tasks, Take Offline (close the confirmation box) Please note that this sql task can take
some time to complete.
Should you get an error, or in case the process seems to newer complete. Then try disconnecting the
connection to the SafeCom SQL instance. Close down SQL Management Studio, and reconnect again. It
should then be possible to bring the database offline. (Or it might in the meantime have changed to the
offline state)

32. In SQL management studio, one by one, right click the 4 safecom databases (sccore, scevent, scpurse,
sctracking) and chose Tasks, Detach (Tick the “Drop connections” box, and hit OK.)

33. Now it is time to move the physical files ((scccore.mdf, sccore.ldf, scevent.mdf, scevent.ldf,
scpurse.mdf, scevent.ldf, sctrackingw.mdf, sctrackingw.ldf)) to the new folder. Remember that the folder
must be on a drive that is visible from Sql Management studio. This means that the drive used must be seen
as a local drive. Network drives can not be used.

34. After moving the SafeCom database files to the new location, make sure that the folder holding the
SafeCom files are assigned same rights as the old folder has. See step 27.

35. In SQL Management studio, (still logged in as the same user), right click “Databases” and choose
“Attach”
Click the Add button, and browse to the folder you copied the 8 SafeCom database files to.
Highlight the sccore.mdf file and hit the OK button.
Click the OK button to add in the database.

36. Repeat step 35. and one by one add in the scevent.mdf, scpurse.mdf and sctrackingw.mdf database.
37. One by one, rightclick the added SafeCom databases and take properties. In the General tab, verify that
the correct user is listed as owner for the database.

(38). If the safecom sql user was intended to be the owner of the databases, but it turns out not to be the
case, then you can run the sql script scChangeOwner.sql as a querry in SQL management studio. The file is
found in the Safecom installation folder. Running the script will force the safecom SQL user to become
owner of the 4 SafeCom databases.

39. Close the SQL Management Studio. On the Slave server start the SafeCom service, the Print spooler
service, and eventual other services you closed down in step. 28

40. On the Master SQL server, start up the SQL Agent for the instance.

41 In SafeCom Administrator, Right click the slave server, and choose “Repair Replication”
This will enable Publising and Distribution again, and setup replication to that slave.
(SafeCom G3 versions older than G3 420*06, does not have the “Repair Replication” option in SafeCom
Administrator. A way to force replication to be setup/repaired, is to open Server Properties for the Slave
server in SafeCom Administrator, and on the Tracking tab toggle Online Tracking/Offline Tracking. Press the
“Apply” button. Wait 2 minutes, then change the setting back to what it was, and press the Apply button
again)

42. Done.