I have used this script to migrate transactions from one recording to another. Simple reassignment of the RecordingID, RecordingStepIDs, and StepGUIDs in the Transaction and TransactionSteps tables, all history comes with the migration. Works from 2.2 to 3.0 Recordings as well as same version, as long as the conditions below are met:
A few conditions:
1. The "old" Recording name must end in a ` (back tick), or specify something else with the @oldRNameSuffix variable.
2. The "new" Recording name should be identical to the old except for the `
3. The step names must be identical, in both number and distinction (unique step names)
4. New recording cannot have any transactions assigned already (test it out, but delete the test transaction when you're satisfied with the recording)
5. Unmanage the transaction before updating
Specify the TransactionID with the @tId variable.
Preview the change with @tCommitChange = 0;
Commit the change with @tCommitChange = 1;
The script will check the conditions above and warn if there's a conflict or error.
Since the playback commands and rest of the recording data is completely held in the SEUM_Recordings and SEUM_RecordingSteps tables, the SEUM_Transactions and SEUM_TransactionSteps tables are simply pass-through pointers associating metric history and recordings. Being that both WPM 2.2 history and WPM 3.0 history are the same, only the type of recording is different. So if you can make a new recording with the same steps as the old one, you can move the transaction and its history to run from the new recording. This keeps existing reports and other dependencies intact.
As a side note, it doesn't have to go from 2.2 to 3.0 Recorder, you can use it simply to update URLs or other items the recorder doesn't give access to, then migrate the transaction to the new (almost-identical) recording, and you won't lose any history!
Script provided as is, no warranty or liability. Use at your own risk. Backup and Test first.
