Picture the following scenario: You have invested a lot of time creating DSDs. You’ve spent time perfecting your SQL queries, publishing them, and your designers (or even yourself) have spent more time creating your template and getting it just right. Then you find you are migrating systems to a new database, and are worried that your outputs are now redundant and will have to be recreated.
There’s a much easier solution. If you’ve used aliases in your SQL query, for example: “SELECT myuseramefield AS UserName FROM mytable”, then you don’t need to recreate your templates at all. The process to migrate to another database would simply be as follows:
1. Add a new database connection into fAdmin. You could just change the connection string for your existing system, but this would immediately impact all DSDs, and this method allows you to keep your current reports working while you migrate to your new database.
2. In fData, open the DSD that drives the templates you want to migrate. Go into your SQL datagroup(s), and change the connection from your old database to your new one, and leaving the aliases the same, change the field names and table names to match your new database, for example your query would now read “SELECT mynewusernamefield AS UserName FROM mynewtable”.
3. Test your DSD and publish it to apply the change, and your template will immediately start working from the new database.
Because your alias remains the same, and the templates drive off this alias, then your template does not need to be updated and the change will immediately take effect.
If you haven’t used an alias, then all is not lost. Simply put one in that matches your old field name. For example, if the query from your old system was “SELECT myusernamefield FROM mytable”, then your new query would be “SELECT mynewusernamefield AS myusernamefield FROM mynewtable”. Your template will then continue to work successfully.
