Back to Top

Cloning an Application with the SQL API

The BuildMaster API is largely a wrapper around the stored procedures in the BuildMaster database. For users who are comfortable writing T-SQL and want to make quick changes, the SQL API may be a good option.


This tutorial was originally designed for BuildMaster v4. The screenshots and concepts may be a little out of date. An updated tutorial for BuildMaster v5 is coming soon.

Note: This can already be done with a built-in feature. Click the gear icon in the top right hand corner to take you to the administration dashboard, click "Create Application" under Applications. On the far right below "More Options" you will see "Duplicate Existing".
Of course, if you would like to do it via the SQL API, you can continue on to the tutorial below.

We'll use the Applications_CloneApplication method for this tutorial, but you can use the same techniques to call any of the API methods. Among other parameters, this method inputs the Application_Id of the application you'd like to clone. This is pretty easy to find.

And as always, you should back-up the BuildMaster database before making any changes.

Step 1: Get the Application Id To Clone

There are three ways to find the Application Id:

  • Querystring – in the web browser, look for the integer immediately following the /applications path
  • SELECT – a simple SELECT * FROM Applications WHERE Application_Name='MyApp' will quickly find the ID
  • Applications_GetApplications – this API method will return all applications in a DataTable, which you can then use to locate yours

Step 2: Set the CONTEXT_INFO

Before directly executing a stored procedure, you need to set the CONTEXT_INFO. This information is used to trigger events and set the value of the CreatedBy and LastModified user name.  This only needs to be done once per connection, and you can use this script to set it:

DECLARE @B VARBINARY(MAX) 
SET @B = CAST('yourname' AS VARBINARY)
SET CONTEXT_INFO @B

Obviously, "yourname" should be replaced with a  more meaningful string, but it doesn't have to be your username. It could be "SQLAPI".

Step 3: Execute the Procedure

The Applications_CloneApplication method is executed just like any normal stored procedure. Here is a simple way to execute this method:

EXEC [Applications_CloneApplication]
  @Application_Id = 8, 
  @LinkAllActionGroups_Indicator = 'N',
  @New_Application_Name = 'MyApp (Clone)'

You could just as easily pass in @New_Application_Id as an output parameter to get the value of the newly created application's ID, and then do something with the ID.

SQL Privileges

The BuildMasterUser_Role is the only role needed when accessing the database, but we do recommend the db_reader role as it allows for direct table queries, which can be useful when figuring out which ID goes to what.

Direct INSERT/UPDATE/DELETE Statements

We do not support or recommend executing any INSERT, UPDATE, or DELETE statements against the BuildMaster SQL Database. It's a complicated schema that can be challenging for even a seasoned Inedo developer to figure out, which is why we don't even do that.

Internal-Use Procedures

A number of stored procedures in the BuildMaster database (such as Builds_CompletePromotion and Executions_GetAndExecuteNextAction) are considered to be "internal use only."  These procedures are not documented on the BuildMaster API Reference and have Internal_Indicator set to "Y" in the __BuildMaster_StoredProcInfo table.

We do not support or recommend calling these procedures.