changing alarms and event storage from SQL to History blocks

Question

Hi, I have a system which I intend to change the alarms and events storage 
 It is now saving to a SQL database and I intend to change it to history blocks. It has been running the last 5 years with the SQL option. I am wondering if there anything to keep in mind that can go wrong or is it just a matter of changing the setting in the configurator and that's it? 
 
 regards 
 Jakob

Richard Köhlerstrand · Answer

Hi Jakob! 
 
 When you select the Traditional option in configurator, it will create the (legacy) A2ALMDB SQL Database for the storage of Alarms, Historian will not accept Alarm or Events from any Application Engine. 
 Any alarm history logging has to be set up manually using the Alarm DB Logger Manager, querying the Galaxy for alarms. This will save any alarm and event that falls within the scope of your configuration.

(This database is not created if you make the option of High speed alarms).

You also need to ensure that you have at least one platform configured as Alarm Provider

If you have been running your system with the 'Traditional' setup and decide to make the switch to 'High speed' you need to manually migrate the data in your A2ALMDB to Historian if your intention is to merge the existing records in to Historian using the aahBlockMigrator.exe found in the folder C:\Program Files (x86)\Wonderware\Historian\x64

Keep in mind that the migration tool will only accept the database name A2ALMDB, and will fail to connect if your alarm database is named something different, such as WWALMDB, and it will fail if the database is created in Consolidated Mode! 
 
 With this said, switching to High Speed will still allow you to log using the legacy option using Alarm DB Logger Manager and your A2ALMDB in parallel, if desired. 
 
 To start the switch you can verify some configuration in your galaxy, Historization of alarms is enabled by default, but its good to know that you have options to change.

Your engine has to be set up to Enable storage to Historian, and perhaps this is already in place if you are logging attribute data to Historian.

Once reviewed, it is important that you shut down and disable your historian, and in version 2023 R2 it is required by the configurator. (but if you have an older version and do not shutdown and disable historian it will not reflect alarm data until historian is shutdown and disabled and then started again). 
 If you have any active trends, you have to restart the session to have them reflect the alarm on the Attributes you log both history and alarms to. 
 In my test i did not need to redeploy any active engines since I already had the above mentioned settings in place in my Galaxy. Once Historian was online again, alarm data was available in my Historian.

Lastly you need to make the changes in any History alarm components, switching to History Blocks, and if you have any 3rd party reporting tools, make proper changes to connect to the Runtime database and the Tables and views available there.

It is of course recommended that you make backups of your Historian prior to making any changes or imports of old alarm data. 
 
 I hope this helps you forward and that you have a smooth 'switch'