ApexSQL Source Control
This article describes how to link a SQL Server database to a Perforce repository that is installed on a dedicated machine (local or a remote one).
Linking a database to a cloud repository is already covered where the Perforce repository hosted on Assembla.com is used as an example. Detailed information about using the cloud based Perforce repository on Assembla.com can be found in the How to link a SQL Server database to an Assembla.com repository using Perforce article.
Before linking a database to a Perforce repository, whether on a local machine (the same machine where ApexSQL Source Control is installed), or to a remote one (Perforce server/repository is not on the same machine where ApexSQL Source Control is installed), there are requirements that must be fulfilled, before the linking process.
Perforce server must be installed and set
To install Perforce server, use the Helix versioning engine
Make sure that the Server component is included in the installation process
By default, a server on a local machine is accessed using the localhost:1666 address, where 1666 is a default port that is used for Perforce.
- Once the Perforce server is installed, a SQL Server database can be linked to a Perforce repository.
Since the process of linking a database to source control is already covered in the How to link a database to a source control system article, where all the steps in the Source control wizard are explained (steps that are common for any source control system), we’ll focus on specific information that should be passed when linking to a Perforce repository.
An important step is to choose Perforce from the Source control system drop-down list, in the Connection type step of the Source control wizard:
Another important step is to pass the appropriate values in the System login step of the source control wizard (the final step in the linking process). When choosing Perforce as a source control system in the first step, the final step will be as follows:
Username and password
When linking a database to a Perforce server that is hosted on a local machine, credentials can be omitted. Even if the client machine where ApexSQL Source Control is installed is in the same domain as the machine where the Perforce server is installed, credentials can be omitted. If for any reason credentials are mandatory, they can be specified.
The Host field should contain the address of the Perforce server. When a local machine is used, it is sufficient to specify localhost:1666 (which is a default address). If this is changed during the Perforce server installation, or later at any point, the actual address must be specified. For example, let’s assume that an instance of the Perforce server is installed on a machine called ApexSQL using the default port 1666, the following should be specified in the host field:
When installing a Perforce server a default depot will be created called “depot”. Assuming that default depot will be used the System login step will be as follows:
All available depot types are supported by ApexSQL Source Control.
A Perforce workspace is important because if it is not specified, a Perforce depot can be accessed but file exchange could not be available. Since we’ll need a Perforce depot to commit SQL database files, a workspace is mandatory.
A workspace name cannot contain special characters (! @, #, $, etc.) and cannot be specified using numbers only. If numbers are to be used in a workspace name, they must be used in combination with letters.
It is important to mention that workspaces for each linked database must be unique for each user. This means that if one developer created a workspace called for example Test other developers cannot specify the same workspace, even if a different depot is used.
Let’s specify a workspace called Dev01Test for the purpose of this article.
Now that we have all the required information, a SQL Server database can be linked by clicking the Finish button in the bottom right section of the Source control wizard:
Q: Is it possible to use a single depot for linking multiple databases?
A: Yes, as long as the workspace for each database is different.
Q: What happens when linking a database to a workspace where another database is already mapped?
A: The error message appears saying that the specified workspace is already in use:
Q: Is it possible to link a SQL Server database to a Perforce repository using both dedicated and shared development models?
A: Yes, selecting a development model is irrelevant in this case. Like with other natively supported source control systems, a database can be linked using any of the available development models.
Q: What happens if the non-exited depot is specified in the Depot field?
A: A warning message appears saying that the specified depot name does not exist:
Q: If the Perforce server is installed on a dedicated machine, is there anything specific that must be installed on a client side?
A: No, if the Perforce server is on a remote machine, the client will need SQL Server Management Studio and ApexSQL Source Control installed. Assuming that a valid connection exists between client and a server machine, no additional configuration is required on a client side in order to link a database to a Perforce repository.
Q: Is it possible to review available depots created on a Perforce server using ApexSQL Source Control?
A: No, this is not available to achieve using ApexSQL Source Control.
To review existing depots on a Perforce server, a command line client, or any GUI client is required to be installed. To get a list of all available depots, execute the following command using the Perforce Command Line Client:
The result will be similar to the following:
Depot depot 2017/06/10 local depot/… ‘Default depot’
Depot TestDepot 2017/06/10 local TestDepot/… ‘Created by Marko. ‘