Just discovered Kevin's answer here which should work: http://inedo.com/support/questions/4058#inline-post-5062

This was indeed removed from v5 for a variety of reasons, but we do plan to bring it back. It was very problematic to display this information on the web after connecting to it from an agent, etc.

A bit late in the game for an answer, but I thought I would add my two cents: Tod is 100% correct, you do not want to use variables within Buildmaster for this, but you do not need to go the length of over-managing either. To resolve this issue: Passwords: Resolve this with the credentials for the database. Database name differences: Have your DBA create a Synonym across the board. For example, if your app is named "DirtyHarry" and on DBDEV is called "RevolverDB" and PRODDEV is called "MagnumDB" just create a synonym "DirtyHarryDB" on both servers, resolving to the actual DB name. Then in all your change scripts use DirtyHarryDB... or just set a synonym on DEV to be the same as PROD DB name or vice-versa. There are quite a few ways you can resolve issues like this, but it is always better to be genericized. We have the same in that we utilize snapshots in DEV that can be in any database location, but in production they are referenced to linked servers. -Kevin

It's alphabetical. We've considered adding in a sequence, but have found that most folks will prefer the old "GWBasic" route of prepending an integer to the name to determine execution order. First SCript Second Script Last script This ordering comes after the release ordering.

We've made settings part of BuildMaster like that in the past (e.g. FormsAuthenticationTimeout). Since I'm not sure how we'll handle this particular setting in the future, you can set the value in machine.config for the time being. You can find the .config here: C:\Windows\Microsoft.NET\Framework[version]\config\machine.config

I went to the Releases table and fixed it by hand, and the sequence is correct now. Thanks.

Hi Arian, BuildMaster's Database Change Management follows the steps outlined in Database Changes Done Right: http://thedailywtf.com/Articles/Database-Changes-Done-Right.aspx So, basically, each script is assoiciated with a release, and BuildMaster change script executer (action, manual, or self-contained executoer) can tell if the script has been run against a database by maintaining a metadata table. You can use this to configure all sorts of patterns, including what (I think) you're refering to. Alex

Good question – we’ll have to fix this in our documentation. The BuildMasterUser_Role is for the BuildMaster Application (WebApp/Service) talking to the BuildMaster Database – doesn’t have really anything to do with deploying to databases. The database deployment bits of BuildMaster need only the permissions that the scripts need to run. You set up the database credentials in a your connection string (or, if you’re using integrated authentication, the service account) – so it’s really up to you. We generally recommend giving db_owner against the target database, since your scripts will generally do a bunch of things like create, alter, etc. But that’s up to you. The script will just error out if permissions aren’t there.

The connection string format is just a typical database connection string. You can follow the examples listed here: http://connectionstrings.com/ Specifying init as "yes" will initialize the database if it hasn't already been initialized. You'll need to specify this if you're running the changescripter tool against a DB for the first time.