go-mssqldb Limitazioni

Questo articolo elenca limitazioni e vincoli noti del go-mssqldb driver.

LastInsertId non è supportato

Il go-mssqldb driver non supporta il database/sqlResult.LastInsertId() metodo. Chiamandolo restituisce un errore:

LastInsertId is not supported. Please use the OUTPUT clause or add
'select ID = convert(bigint, SCOPE_IDENTITY())' to the end of your query.

Soluzione alternativa: Usa una OUTPUT clausola nell'istruzione INSERT o nella query SCOPE_IDENTITY() separatamente.

I Multiple Active Result Set (MARS) non sono supportati

Il driver non supporta MARS. Ogni connessione può avere solo una query o istruzione attiva alla volta. Se devi eseguire query concorrenti, usa connessioni separate dal pool.

Ambito temporaneo della tabella con pool di connessione

Il comportamento temporaneo delle tabelle segue le regole di scoping di SQL Server, ma il connection pooling modifica il modo in cui questo comportamento appare nel codice applicativo:

  • Le tabelle temporanee locali (#name) sono ricondotte a una sessione (connessione).
  • Le tabelle temporanee globali (##name) sono visibili ad altre sessioni mentre la sessione di creazione rimane aperta.

Con database/sql, separate db.Exec e db.Query chiamate potrebbero usare connessioni pool diverse. Una tabella temporanea locale creata in una chiamata non è visibile nella chiamata successiva quando quella viene eseguita su una connessione diversa.

Per le tabelle temporanee globali, la visibilità tra le connessioni funziona come previsto, ma le collisioni del ciclo di vita e dei nomi richiedono ancora attenzione nei carichi di lavoro concorrenti.

Guida: Utilizzare db.Conn(ctx) l'inserimento di operazioni correlate su una connessione, oppure di inserire operazioni in una transazione. Utilizzare tabelle temporanee globali solo quando è richiesta la visibilità tra sessioni.

Per i pattern di implementazione, vedi Tabelle temporanee e stored procedure, Pool di connessione e Tabella temporanea non trovata.

Vincoli sempre criptati

  • Copia in blocco con colonne criptate: Il driver non supporta operazioni di copia in massa su tabelle con colonne Always Crittymed.
  • Enclave sicuri: Il driver non supporta Always Encrypted con enclave sicure.
  • Registrazione del fornitore: Devi importare il pacchetto del provider chiave (localcert, akv) come importazione a effetto collaterale. Senza di esso, il driver non può decriptare i dati.
  • Abbinamento esatto del tipo di parametro: I parametri criptati devono corrispondere strettamente al tipo di colonna di SQL Server. Un Go string predefinito diventa nvarchar, che può fallire contro tipi di parametri crittografati più specifici.
  • Cifrato char e varchar testo: Inserimenti e aggiornamenti contro colonne char criptate varchar o colonne sono attualmente limitati. Preferisci cifrati nchar o nvarchar colonne quando hai bisogno di Always Encrypted per i dati di testo.

Versioni più vecchie di SQL Server e TLS

Le versioni più vecchie di SQL Server fuori supporto potrebbero non supportare TLS 1.2 o versioni successive. Quando si connette a queste versioni con encrypt=true, la connessione potrebbe guastarsi se il server non riesce a negoziare una versione TLS compatibile.

Soluzione alternativa: Usa encrypt=false o aggiorna a una versione supportata di SQL Server.

Nome driver mssql obsoleto

Il nome mssql del driver (usato con sql.Open("mssql", ...)) è obsoleto. Usare sqlserver invece:

// Deprecated
db, err := sql.Open("mssql", connString)

// Recommended
db, err := sql.Open("sqlserver", connString)

Il nome del mssql driver esegue la sostituzione dei token parametri, convertendo ? i segnaposto in @p1, @p2, e nomi ordinali simili. Il sqlserver nome del driver richiede parametri esplicitamente nominati e fornisce un comportamento più prevedibile.

Se hai bisogno di un utilizzo basato sql.OpenDB su connettori e devi preservare temporaneamente il comportamento legacy di riscrittura del testo di query, usa NewConnectorWithProcessQueryText. Per il nuovo codice, preferisci il sqlserver nome del driver e parametri espliciti.

colonne uniidentifier

Il driver restituisce uniqueidentifier i valori delle colonne come array grezzi []byte di default. Usare mssql.UniqueIdentifier come destinazione di scansione per ottenere stringhe standard formattate GUID.

Nessuna compatibilità ODBC

Il driver è una pura implementazione di Go e non utilizza né dipende da unixODBC, FreeTDS o dal driver Microsoft ODBC. Le funzionalità specifiche di ODBC (configurazione DSN, tracciamento ODBC) non sono disponibili.

Connessioni con tubi nominati

Le connessioni di pipe nominate potrebbero richiedere permessi specifici del file system sull'endpoint del pipe. Su Linux, il client SMB deve essere configurato per l'accesso a pipe nominato.

Precisione del galleggiamento

Il tipo di float64 Go fornisce circa 15-16 cifre decimali significative. I SQL Server decimal e numeric i tipi possono rappresentare fino a 38 cifre di precisione. Quando si scansionano decimal/numeric colonne in float64, può verificarsi una perdita di precisione per valori con più di 15 cifre significative.

Soluzione alternativa: scansiona decimal/numeric le colonne e string usa una libreria decimale di terze parti come shopspring/decimal (github.com/shopspring/decimal) o cockroachdb/apd (github.com/cockroachdb/apd) per una calcolo preciso. Per i pattern, vedi Data type mappings.