go-mssqldb

Microsoft SQL server driver written in go language

1,816

501

1,816

175

View on GitHub

Top Related Projects

sqlx

16,124

general purpose extensions to golang's database/sql

pgx

10,547

PostgreSQL driver and toolkit for Go

gorm

36,742

The fantastic ORM library for Golang, aims to be developer friendly

pq

9,065

Pure Go Postgres driver for database/sql

Quick Overview

The denisenkom/go-mssqldb is a Go language driver for Microsoft SQL Server and Azure SQL Database. It provides a native Go implementation for connecting to and interacting with SQL Server databases, offering full support for the TDS (Tabular Data Stream) protocol.

Pros

Native Go implementation, ensuring better performance and compatibility with Go applications
Supports both Windows and Linux platforms
Includes support for important features like transactions, prepared statements, and connection pooling
Active development and maintenance, with regular updates and bug fixes

Cons

Limited support for older SQL Server versions (pre-2008)
Some advanced SQL Server features may not be fully implemented
Documentation could be more comprehensive, especially for advanced use cases
May have occasional compatibility issues with certain SQL Server configurations

Code Examples

Connecting to a database:

db, err := sql.Open("sqlserver", "server=localhost;user id=sa;password=secret;database=master")
if err != nil {
    log.Fatal(err)
}
defer db.Close()

Executing a simple query:

rows, err := db.Query("SELECT * FROM users WHERE active = @active", sql.Named("active", true))
if err != nil {
    log.Fatal(err)
}
defer rows.Close()

for rows.Next() {
    var id int
    var name string
    if err := rows.Scan(&id, &name); err != nil {
        log.Fatal(err)
    }
    fmt.Printf("ID: %d, Name: %s\n", id, name)
}

Using a prepared statement:

stmt, err := db.Prepare("INSERT INTO users(name, email) VALUES(@p1, @p2)")
if err != nil {
    log.Fatal(err)
}
defer stmt.Close()

_, err = stmt.Exec("John Doe", "john@example.com")
if err != nil {
    log.Fatal(err)
}

Getting Started

To use go-mssqldb in your Go project:

Install the package:

go get github.com/denisenkom/go-mssqldb

Import the package in your Go code:

import (
    "database/sql"
    _ "github.com/denisenkom/go-mssqldb"
)

Use the "sqlserver" driver name when opening a database connection:

db, err := sql.Open("sqlserver", "server=localhost;user id=sa;password=secret;database=master")

Start using the db object to interact with your SQL Server database.

Competitor Comparisons

sqlx

16,124

general purpose extensions to golang's database/sql

Pros of sqlx

Provides a set of extensions on top of Go's database/sql package, offering more convenient data access patterns
Supports named parameter queries, making SQL statements more readable and maintainable
Offers easy struct scanning, simplifying the process of mapping query results to Go structs

Cons of sqlx

Limited to SQL databases, while go-mssqldb is specifically designed for Microsoft SQL Server
May introduce a slight performance overhead due to additional abstraction layers
Requires learning a new API, which might not be necessary for simpler database operations

Code Comparison

sqlx:

db, err := sqlx.Connect("postgres", "user=foo dbname=bar sslmode=disable")
rows, err := db.NamedQuery(`SELECT * FROM users WHERE name=:name`, map[string]interface{}{"name": "John"})
var users []User
err = db.Select(&users, "SELECT * FROM users")

go-mssqldb:

db, err := sql.Open("mssql", "server=localhost;user id=sa;password=secret")
rows, err := db.Query("SELECT * FROM users WHERE name = @p1", "John")
var users []User
for rows.Next() {
    var u User
    err = rows.Scan(&u.ID, &u.Name)
    users = append(users, u)
}

pgx

10,547

PostgreSQL driver and toolkit for Go

Pros of pgx

Better performance: pgx is optimized for PostgreSQL, offering faster query execution and data retrieval
More PostgreSQL-specific features: Supports advanced PostgreSQL functionalities like LISTEN/NOTIFY and COPY
Built-in connection pooling: Includes a connection pool implementation, simplifying concurrent database access

Cons of pgx

PostgreSQL-only: Unlike go-mssqldb, pgx is not designed for use with other database systems
Steeper learning curve: May require more time to master due to its extensive feature set

Code Comparison

pgx:

conn, err := pgx.Connect(context.Background(), "postgres://username:password@localhost:5432/database")
rows, err := conn.Query(context.Background(), "SELECT * FROM users WHERE id = $1", id)

go-mssqldb:

db, err := sql.Open("sqlserver", "server=localhost;user id=username;password=password;database=database")
rows, err := db.Query("SELECT * FROM users WHERE id = @p1", sql.Named("p1", id))

Both libraries provide similar basic functionality for connecting to and querying databases. However, pgx offers more PostgreSQL-specific optimizations and features, while go-mssqldb is designed for Microsoft SQL Server compatibility. The choice between them largely depends on the specific database system being used and the required features for the project.

gorm

36,742

The fantastic ORM library for Golang, aims to be developer friendly

Pros of gorm

Higher-level abstraction, providing ORM functionality for easier database operations
Supports multiple databases, not limited to MS SQL Server
Offers features like migrations, associations, and hooks for more complex data modeling

Cons of gorm

May introduce performance overhead due to its abstraction layer
Steeper learning curve for developers new to ORM concepts
Less fine-grained control over SQL queries compared to direct database drivers

Code Comparison

gorm example:

db.Create(&User{Name: "John", Age: 30})
var user User
db.First(&user, "name = ?", "John")

go-mssqldb example:

_, err := db.Exec("INSERT INTO Users (Name, Age) VALUES (@p1, @p2)", "John", 30)
row := db.QueryRow("SELECT * FROM Users WHERE Name = @p1", "John")
err := row.Scan(&user.ID, &user.Name, &user.Age)

gorm provides a more abstracted and concise way to interact with the database, while go-mssqldb offers direct SQL query execution, giving more control but requiring more verbose code.

pq

9,065

Pure Go Postgres driver for database/sql

Pros of pq

Mature and widely adopted PostgreSQL driver for Go
Extensive feature support, including native SSL and LISTEN/NOTIFY
Well-documented with a large community and ecosystem

Cons of pq

Limited to PostgreSQL databases only
Less active development compared to go-mssqldb
Lacks some advanced features like Always Encrypted

Code Comparison

pq:

import (
    "database/sql"
    _ "github.com/lib/pq"
)

db, err := sql.Open("postgres", "user=pqgotest dbname=pqgotest sslmode=verify-full")

go-mssqldb:

import (
    "database/sql"
    _ "github.com/denisenkom/go-mssqldb"
)

db, err := sql.Open("sqlserver", "server=localhost;user id=sa;password=secret")

Both drivers implement the database/sql interface, making them interchangeable in many cases. The main difference lies in the connection string format and database-specific features.

pq is the go-to choice for PostgreSQL databases, offering robust support and a large ecosystem. However, go-mssqldb provides better performance and more advanced features for SQL Server databases. The choice between the two largely depends on the target database system and specific project requirements.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

A pure Go MSSQL driver for Go's database/sql package

For more recent updates, see the Microsoft fork.

Install

Requires Go 1.8 or above.

Install with go get github.com/denisenkom/go-mssqldb .

Connection Parameters and DSN

The recommended connection string uses a URL format: sqlserver://username:password@host/instance?param1=value&param2=value Other supported formats are listed below.

Common parameters

user id - enter the SQL Server Authentication user id or the Windows Authentication user id in the DOMAIN\User format. On Windows, if user id is empty or missing Single-Sign-On is used. The user domain sensitive to the case which is defined in the connection string.
password
database
connection timeout - in seconds (default is 0 for no timeout), set to 0 for no timeout. Recommended to set to 0 and use context to manage query and connection timeouts.
dial timeout - in seconds (default is 15), set to 0 for no timeout
encrypt
- disable - Data send between client and server is not encrypted.
- false - Data sent between client and server is not encrypted beyond the login packet. (Default)
- true - Data sent between client and server is encrypted.
app name - The application name (default is go-mssqldb)

Connection parameters for ODBC and ADO style connection strings

server - host or host\instance (default localhost)
port - used only when there is no instance in server (default 1433)

Less common parameters

keepAlive - in seconds; 0 to disable (default is 30)
failoverpartner - host or host\instance (default is no partner).
failoverport - used only when there is no instance in failoverpartner (default 1433)
packet size - in bytes; 512 to 32767 (default is 4096)
- Encrypted connections have a maximum packet size of 16383 bytes
- Further information on usage: https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/configure-the-network-packet-size-server-configuration-option
log - logging flags (default 0/no logging, 63 for full logging)
- 1 log errors
- 2 log messages
- 4 log rows affected
- 8 trace sql statements
- 16 log statement parameters
- 32 log transaction begin/end
TrustServerCertificate
- false - Server certificate is checked. Default is false if encrypt is specified.
- true - Server certificate is not checked. Default is true if encrypt is not specified. If trust server certificate is true, driver accepts any certificate presented by the server and any host name in that certificate. In this mode, TLS is susceptible to man-in-the-middle attacks. This should be used only for testing.
certificate - The file that contains the public key certificate of the CA that signed the SQL Server certificate. The specified certificate overrides the go platform specific CA certificates.
hostNameInCertificate - Specifies the Common Name (CN) in the server certificate. Default value is the server host.
ServerSPN - The kerberos SPN (Service Principal Name) for the server. Default is MSSQLSvc/host:port.
Workstation ID - The workstation name (default is the host name)
ApplicationIntent - Can be given the value ReadOnly to initiate a read-only connection to an Availability Group listener. The database must be specified when connecting with Application Intent set to ReadOnly.

The connection string can be specified in one of three formats

URL: with sqlserver scheme. username and password appears before the host. Any instance appears as the first segment in the path. All other options are query parameters. Examples:
- sqlserver://username:password@host/instance?param1=value&param2=value
- sqlserver://username:password@host:port?param1=value&param2=value
- sqlserver://sa@localhost/SQLExpress?database=master&connection+timeout=30 // `SQLExpress instance.
- sqlserver://sa:mypass@localhost?database=master&connection+timeout=30 // username=sa, password=mypass.
- sqlserver://sa:mypass@localhost:1234?database=master&connection+timeout=30 // port 1234 on localhost.
- sqlserver://sa:my%7Bpass@somehost?connection+timeout=30 // password is "my{pass" A string of this format can be constructed using the URL type in the net/url package.
```
query := url.Values{}
query.Add("app name", "MyAppName")

u := &url.URL{
	Scheme:   "sqlserver",
	User:     url.UserPassword(username, password),
	Host:     fmt.Sprintf("%s:%d", hostname, port),
	// Path:  instance, // if connecting to an instance instead of a port
	RawQuery: query.Encode(),
}
db, err := sql.Open("sqlserver", u.String())
```
ADO: key=value pairs separated by ;. Values may not contain ;, leading and trailing whitespace is ignored. Examples:
- server=localhost\\SQLExpress;user id=sa;database=master;app name=MyAppName
- server=localhost;user id=sa;database=master;app name=MyAppName
ADO strings support synonyms for database, app name, user id, and server
- server <= addr, address, network address, data source
- user id <= user, uid
- database <= initial catalog
- app name <= application name
ODBC: Prefix with odbc, key=value pairs separated by ;. Allow ; by wrapping values in {}. Examples:
- odbc:server=localhost\\SQLExpress;user id=sa;database=master;app name=MyAppName
- odbc:server=localhost;user id=sa;database=master;app name=MyAppName
- odbc:server=localhost;user id=sa;password={foo;bar} // Value marked with {}, password is "foo;bar"
- odbc:server=localhost;user id=sa;password={foo{bar} // Value marked with {}, password is "foo{bar"
- odbc:server=localhost;user id=sa;password={foobar } // Value marked with {}, password is "foobar "
- odbc:server=localhost;user id=sa;password=foo{bar // Literal {, password is "foo{bar"
- odbc:server=localhost;user id=sa;password=foo}bar // Literal }, password is "foo}bar"
- odbc:server=localhost;user id=sa;password={foo{bar} // Literal {, password is "foo{bar"
- odbc:server=localhost;user id=sa;password={foo}}bar} // Escaped } with}}`, password is "foo}bar"

Azure Active Directory authentication

Azure Active Directory authentication uses temporary authentication tokens to authenticate. The mssql package does not provide an implementation to obtain tokens: instead, import the azuread package and use driver name azuresql. This driver uses azidentity to acquire tokens using a variety of credential types.

The credential type is determined by the new fedauth connection string parameter.

fedauth=ActiveDirectoryServicePrincipal or fedauth=ActiveDirectoryApplication - authenticates using an Azure Active Directory application client ID and client secret or certificate. Implemented using ClientSecretCredential or CertificateCredential
- clientcertpath=<path to certificate file>;password=<certificate password> or
- password=<client secret>
- user id=<application id>[@tenantid] Note the @tenantid component can be omitted if the server's tenant is the same as the application's tenant.
fedauth=ActiveDirectoryPassword - authenticates using a user name and password.
- user id=username@domain
- password=<password>
- applicationclientid=<application id> - This guid identifies an Azure Active Directory enterprise application that the AAD admin has approved for accessing Azure SQL database resources in the tenant. This driver does not have an associated application id of its own.
fedauth=ActiveDirectoryDefault - authenticates using a chained set of credentials. The chain is built from EnvironmentCredential -> ManagedIdentityCredential->AzureCLICredential. See DefaultAzureCredential docs for instructions on setting up your host environment to use it. Using this option allows you to have the same connection string in a service deployment as on your interactive development machine.
fedauth=ActiveDirectoryManagedIdentity or fedauth=ActiveDirectoryMSI - authenticates using a system-assigned or user-assigned Azure Managed Identity.
- user id=<identity id> - optional id of user-assigned managed identity. If empty, system-assigned managed identity is used.
fedauth=ActiveDirectoryInteractive - authenticates using credentials acquired from an external web browser. Only suitable for use with human interaction.
- applicationclientid=<application id> - This guid identifies an Azure Active Directory enterprise application that the AAD admin has approved for accessing Azure SQL database resources in the tenant. This driver does not have an associated application id of its own.


import (
  "database/sql"
  "net/url"

  // Import the Azure AD driver module (also imports the regular driver package)
  "github.com/denisenkom/go-mssqldb/azuread"
)

func ConnectWithMSI() (*sql.DB, error) {
  return sql.Open(azuread.DriverName, "sqlserver://azuresql.database.windows.net?database=yourdb&fedauth=ActiveDirectoryMSI")
}

Executing Stored Procedures

To run a stored procedure, set the query text to the procedure name:


var account = "abc"
_, err := db.ExecContext(ctx, "sp_RunMe",
	sql.Named("ID", 123),
	sql.Named("Account", sql.Out{Dest: &account}),
)

Reading Output Parameters from a Stored Procedure with Resultset

To read output parameters from a stored procedure with resultset, make sure you read all the rows before reading the output parameters:


sqltextcreate := `
CREATE PROCEDURE spwithoutputandrows
	@bitparam BIT OUTPUT
AS BEGIN
	SET @bitparam = 1
	SELECT 'Row 1'
END
`
var bitout int64
rows, err := db.QueryContext(ctx, "spwithoutputandrows", sql.Named("bitparam", sql.Out{Dest: &bitout}))
var strrow string
for rows.Next() {
	err = rows.Scan(&strrow)
}
fmt.Printf("bitparam is %d", bitout)

Caveat for local temporary tables

Due to protocol limitations, temporary tables will only be allocated on the connection as a result of executing a query with zero parameters. The following query will, due to the use of a parameter, execute in its own session, and #mytemp will be de-allocated right away:

conn, err := pool.Conn(ctx)
defer conn.Close()
_, err := conn.ExecContext(ctx, "select @p1 as x into #mytemp", 1)
// at this point #mytemp is already dropped again as the session of the ExecContext is over

To work around this, always explicitly create the local temporary table in a query without any parameters. As a special case, the driver will then be able to execute the query directly on the connection-scoped session. The following example works:

conn, err := pool.Conn(ctx)

// Set us up so that temp table is always cleaned up, since conn.Close()
// merely returns conn to pool, rather than actually closing the connection.
defer func() {
	_, _ = conn.ExecContext(ctx, "drop table #mytemp")  // always clean up
	conn.Close() // merely returns conn to pool
}()


// Since we not pass any parameters below, the query will execute on the scope of
// the connection and succeed in creating the table.
_, err := conn.ExecContext(ctx, "create table #mytemp ( x int )")

// #mytemp is now available even if you pass parameters
_, err := conn.ExecContext(ctx, "insert into #mytemp (x) values (@p1)", 1)

Return Status

To get the procedure return status, pass into the parameters a *mssql.ReturnStatus. For example:


var rs mssql.ReturnStatus
_, err := db.ExecContext(ctx, "theproc", &rs)
log.Printf("status=%d", rs)

var rs mssql.ReturnStatus
_, err := db.QueryContext(ctx, "theproc", &rs)
for rows.Next() {
	err = rows.Scan(&val)
}
log.Printf("status=%d", rs)

Limitation: ReturnStatus cannot be retrieved using QueryRow.

Parameters

The sqlserver driver uses normal MS SQL Server syntax and expects parameters in the sql query to be in the form of either @Name or @p1 to @pN (ordinal position).


db.QueryContext(ctx, `select * from t where ID = @ID and Name = @p2;`, sql.Named("ID", 6), "Bob")

Parameter Types

To pass specific types to the query parameters, say varchar or date types, you must convert the types to the type before passing in. The following types are supported:

string -> nvarchar
mssql.VarChar -> varchar
time.Time -> datetimeoffset or datetime (TDS version dependent)
mssql.DateTime1 -> datetime
mssql.DateTimeOffset -> datetimeoffset
"github.com/golang-sql/civil".Date -> date
"github.com/golang-sql/civil".DateTime -> datetime2
"github.com/golang-sql/civil".Time -> time
mssql.TVP -> Table Value Parameter (TDS version dependent)

Important Notes

LastInsertId should not be used with this driver (or SQL Server) due to how the TDS protocol works. Please use the OUTPUT Clause or add a select ID = convert(bigint, SCOPE_IDENTITY()); to the end of your query (ref SCOPE_IDENTITY). This will ensure you are getting the correct ID and will prevent a network round trip.
NewConnector may be used with OpenDB.
Connector.SessionInitSQL may be set to set any driver specific session settings after the session has been reset. If empty the session will still be reset but use the database defaults in Go1.10+.

Features

Can be used with SQL Server 2005 or newer
Can be used with Microsoft Azure SQL Database
Can be used on all go supported platforms (e.g. Linux, Mac OS X and Windows)
Supports new date/time types: date, time, datetime2, datetimeoffset
Supports string parameters longer than 8000 characters
Supports encryption using SSL/TLS
Supports SQL Server and Windows Authentication
Supports Single-Sign-On on Windows
Supports connections to AlwaysOn Availability Group listeners, including re-direction to read-only replicas.
Supports query notifications

Tests

go test is used for testing. A running instance of MSSQL server is required. Environment variables are used to pass login information.

Example:

    env SQLSERVER_DSN=sqlserver://user:pass@hostname/instance?database=test1 go test

AZURESERVER_DSN environment variable provides the connection string for Azure Active Directory-based authentication. If it's not set the AAD test will be skipped.

Deprecated

These features still exist in the driver, but they are are deprecated.

Query Parameter Token Replace (driver "mssql")

If you use the driver name "mssql" (rather then "sqlserver") the SQL text will be loosly parsed and an attempt to extract identifiers using one of

?
?nnn
:nnn
$nnn

will be used. This is not recommended with SQL Server. There is at least one existing won't fix issue with the query parsing.

Use the native "@Name" parameters instead with the "sqlserver" driver name.

Known Issues

SQL Server 2008 and 2008 R2 engine cannot handle login records when SSL encryption is not disabled. To fix SQL Server 2008 R2 issue, install SQL Server 2008 R2 Service Pack 2. To fix SQL Server 2008 issue, install Microsoft SQL Server 2008 Service Pack 3 and Cumulative update package 3 for SQL Server 2008 SP3. More information: http://support.microsoft.com/kb/2653857

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot