1. Home
  2. Help
  3. FAQ
  4. General

General

Is there a demo version of VersionSQL?

Yes! Download VersionSQL and connect to a SQL Server database to automatically start a free trial of VersionSQL Professional, no credit card required.

What other software do I need to be able to use VersionSQL?

In order to use VersionSQL to commit your database code to version control, you need:

Installed on your computer:

  • SQL Server Management Studio 2012 or newer
  • VersionSQL

Available on your computer, local network, or cloud-hosted:

  • A SQL Server instance with at least one database
    • This could be SQL Server Express, SQL Server Enterprise, SQL Azure, etc.
  • A version control system, with a project repository created and initialized.
    • There are a plethora of options available here. Some of the more popular examples include Azure DevOps, BitBucket, GitHub, GitLab, and VisualSVN. This system will give you an https repository path to supply to VersionSQL.
    • You probably already have a version control system available for versioning software code. VersionSQL can commit SQL side-by-side in a repository with existing code if you so choose.
    • Click here for more information on version control

Can I run VersionSQL in a locked-down environment?

Yes. Registration is handled via an encrypted keyfile supplied upon purchase. There’s no online activation required.

Is VersionSQL FIPS compliant?

Yes, VersionSQL complies with the Federal Information Processing Standard (FIPS) and can be run on computers with FIPS compliance enforced.

Will VersionSQL continue if it runs into an error?

Whether VersionSQL can ignore the error and continue depends on where the error occurred. If the error occurs while comparing object contents (for instance, if an object is encrypted), it’ll display an error but continue on. The commit and push operation itself is atomic (all or nothing), so an error during commit or push stops everything.

Can VersionSQL connect to local repositories?

VersionSQL supports connecting to remote repositories (like GitHub) as well as locally-hosted bare git repos ("git –bare init") and local working copies.

For local working copies, choose the "Folder" repository type and the appropriate post-commit command when setting up a connection.

Where is VersionSQL's error log stored?

VersionSQL\’s error log file is saved to %LOCALAPPDATA%\VersionSQL\logs(in other words, C:\Users[username]\AppData\Local\VersionSQL\logs)

What local files does VersionSQL create?

VersionSQL reads and writes files in a few locations:

  1. Application binaries are stored in Program Files
  2. Application settings, logs, and some temporary files are kept in %localappdata%
  3. Short-lived temporary files (e.g. diffs) are created in the Windows temp folder, then deleted after use
  4. SQL scripts are written to the specified path if you select the Folder repository type.

Additionally, VersionSQL will scan the locations of known diff and merge tools in order to auto-configure diff and merge settings.

Where is VersionSQL made?

VersionSQL is made in the USA.

Can I choose to commit only stored procedures?

Yes, each database object type can be committed independently by
right-clicking on e.g. the Stored Procedures folder and selecting Commit.

Can I commit multiple objects at once?

You can commit multiple objects by right-clicking on either the folder or database level and selecting "Commit", then unchecking items you don’t want committed from the list.

Does VersionSQL write to the database?

No, VersionSQL only writes to the source control repository and local files. All database operations are read-only.

How does VersionSQL handle SQL Server Availability Groups?

VersionSQL uses the VIEW SERVER STATE permission to identify whether the target server is part of a Sql Server Always On Availability Group or Cluster. If it is, VersionSQL uses the name of the availability group in the committed files’ folder structure instead of the name of the individual server to which it is connected.

This can be disabled from the VersionSQL->Settings menu, Advanced tab, by unchecking Replace server name with Availability Group name, if present.

How does VersionSQL work when everyone has their own instance of SQL Server (dedicated database development model)?

The root computer_name folder is the name of the computer hosting the SQL Server, so it depends on whether your database development model is shared (one SQL Server) or dedicated (everybody has their own local SQL Server).

If each developer works on their own local SQL Server, then each developer’s work will be committed to a different root folder (user1_pc_name, user2_pc_name, etc).

If everybody works against the same SQL Server, then whenever anyone commits it will be written to the same root folder, overwriting the file if it already exists. In essence, the repo will mirror the database.

How does VersionSQL work when everyone uses the same central database (shared database development model)?

The root computer_name folder is the name of the computer hosting the SQL Server, so it depends on whether your database development model is shared (one SQL Server) or dedicated (everybody has their own local SQL Server).

If everybody connects to the same SQL Server, then whatever changes each person makes will be written to the same root folder, overwriting the file if it already exists. The repo will mirror the database.

Is VersionSQL able to generate a list of all of the objects that have been changed since the last commit was made?

Yes, when you run the commit operation against the database or a folder within it, VersionSQL will pull up a list of changed objects that lets you see changes and decide which to commit.

Was this article helpful to you? Yes No

How can we help?