| QUOTE (Lt.Ranger.Bob @ July 19, 2013 04:02 pm) |
| What I have done for the Merge Database macro is to create custom copies that point to the databases I wish to merge. It is a lot of work to upgrade them when a revision is released but I did not know of another way to be able to automate the merging of these databases. If you would like to see one of these custom Merge macros I would be happy to post them but basically all I did was to rename the Merge.gsk and Merge.xml files to something like Merge Arizona.gsk and Merge Arizona.xml where the only change in the Arizona merge gsk file is to point to the Arizona.xml file which contains the required database information for this merge. I run this custom Merge macro in a Wrapper macro... |
FYI, another way to do this, so that you have only one copy of MergeDBs that can be updated easily, would be to modify the settings file (MergeDBs.xml) before running the MergeDBs macro. We use macro code to replace whatever settings we need in the saved settings file, then when we call the MergeDBs macro, it will use the replaced settings.
For example, adding this code to your wrapper macro before calling MergeDBs would replace the name of the first source database in the XML file with "Temp":
| GSK |
#Set the file name $FileName=SlashAdd($_AppData) + "macros/MergeDBs.xml" #Read the file into the variable "@Data" $Data = GetFile($FileName) IF Left($Data,7) = "*Error*" PAUSE Msg="$Data" CANCEL ENDIF #Replace the current name for the first source database with "Temp" $ThisDB="<Name>SourceDB1</Name>" + $_CrLf + " <Type>String</Type>" + $_CrLf + " <Data>Temp</Data>" $Data=RegExReplace("(?s)<Name>SourceDB1<.*?<Type>String</Type>.*?<Data>.*?</Data>",$Data,$ThisDB) #Write the xml file back to disk $WriteFile = PutFile($FileName,$Data) IF Left($WriteFile,7) = "*Error*" PAUSE Msg="$WriteFile" CANCEL ENDIF |
You could repeat the above code for each source database replacing "DB1" in the above code with "DB2" or "DB3" and "Temp" with whatever the database name should be to modify the settings for the second or third source database.
Something similar could be done for the destination database or other settings. Given that you already have it working with multiple copies of MergeDBs, it may not be worth the effort, but I thought I'd let you know for future reference.