Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article énumère les limitations et contraintes connues du go-mssqldb pilote.
LastInsertId n’est pas pris en charge
Le go-mssqldb pilote ne prend pas en charge cette database/sqlResult.LastInsertId() méthode. L’appeler renvoie une erreur :
LastInsertId is not supported. Please use the OUTPUT clause or add
'select ID = convert(bigint, SCOPE_IDENTITY())' to the end of your query.
Solution de contournement : Utilisez une OUTPUT clause dans l’instruction ou la INSERT requête SCOPE_IDENTITY() séparément.
Les ensembles de résultats actifs multiples (MARS) ne sont pas pris en charge
Le pilote ne supporte pas MARS. Chaque connexion ne peut avoir qu’une seule requête ou instruction active à la fois. Si vous devez lancer des requêtes simultanées, utilisez des connexions séparées du pool.
Portée temporaire de table avec pooling de connexions
Le comportement temporaire des tables suit les règles de cadrage de SQL Server, mais le pooling de connexions modifie la façon dont ce comportement apparaît dans le code applicatif :
- Les tables temporaires locales (
#name) sont limitées à une session (connexion). - Les tables temporaires globales (
##name) sont visibles pour les autres sessions tant que la session de création reste ouverte.
Avec , séparé database/sqldb.Exec et db.Query appels peut utiliser des connexions poolées différentes. Une table temporaire locale créée lors d’un appel n’est pas visible lors de l’appel suivant lorsque celui-ci s’exécute sur une autre connexion.
Pour les tables temporaires globales, la visibilité entre connexions fonctionne comme prévu, mais les collisions du cycle de vie et de la nomenclature nécessitent toujours une attention particulière dans les charges de travail concurrentes.
Conseils : Utilisez db.Conn(ctx) pour épingler des opérations liées à une connexion, ou pour encapsuler les opérations dans une transaction. Utilisez des tables temporaires globales uniquement lorsque la visibilité inter-sessions est requise.
Pour les modèles d’implémentation, voir Tables temporaires et procédures stockées, Pooling de connexions et Table temporaire non trouvées.
Contraintes toujours chiffrées
- Copie en bloc avec colonnes chiffrées : Le pilote ne prend pas en charge les opérations de copie en masse sur des tables avec des colonnes Toujours Cryptées.
- Enclaves sécurisées : Le pilote ne supporte pas le chiffrement toujours avec les enclaves sécurisées.
-
Enregistrement du fournisseur : Vous devez importer le package fournisseur clé (
localcert,akv) en tant qu’importation à effet secondaire. Sans cela, le pilote ne peut pas déchiffrer les données. -
Correspondance exacte du type de paramètres : Les paramètres chiffrés doivent correspondre étroitement au type de colonne SQL Server. Un Go
stringpar défaut devientnvarchar, ce qui peut échouer contre des types de paramètres chiffrés plus spécifiques. -
Chiffré
charetvarchartexte : Les insertions et mises à jour contre les colonnes chiffréescharvarcharsont actuellement limitées. Privilégiez les chiffresncharounvarcharles colonnes quand vous avez besoin de Toujours Chiffré pour les données textuelles.
Anciennes versions de SQL Server et TLS
Les versions plus anciennes de SQL Server non prises en charge peuvent ne pas prendre en charge TLS 1.2 ou ultérieures. Lors de la connexion à ces versions avec encrypt=true, la connexion peut échouer si le serveur ne peut pas négocier une version TLS compatible.
Solution de contournement : Utilisez encrypt=false ou mettez à jour une version prise en charge de SQL Server.
Nom de pilote mssql obsolète
Le nom mssql du pilote (utilisé avec sql.Open("mssql", ...)) est obsolète. Utilisez sqlserver à la place :
// Deprecated
db, err := sql.Open("mssql", connString)
// Recommended
db, err := sql.Open("sqlserver", connString)
Le nom du mssql pilote effectue le remplacement de jetons de paramètres, convertissant ? des réserveurs en @p1, @p2, et des noms ordinaux similaires. Le nom du sqlserver pilote nécessite des paramètres nommés explicites et offre un comportement plus prévisible.
Si vous avez besoin d’une utilisation basée sql.OpenDB sur un connecteur et que vous devez temporairement préserver le comportement hérité de réécriture de texte de requête, utilisez NewConnectorWithProcessQueryText. Pour le nouveau code, privilégiez le nom du sqlserver pilote et les paramètres explicites.
colonnes uniqueidentifiable
Le pilote renvoie uniqueidentifier par défaut les valeurs des colonnes sous forme de matrices brutes []byte . Utilisez mssql.UniqueIdentifier comme destination de balayage pour obtenir des chaînes de caractères standard formatées par GUID.
Aucune compatibilité ODBC
Le pilote est une implémentation pure de Go et n'utilise ni ne dépend de unixODBC, FreeTDS ou du pilote Microsoft ODBC. Les fonctionnalités spécifiques à ODBC (configuration DSN, traçage ODBC) ne sont pas disponibles.
Connexions de tuyauterie nommées
Les connexions de pipe nommées peuvent nécessiter des permissions spécifiques du système de fichiers sur le point de terminaison du pipe. Sous Linux, le client SMB doit être configuré pour un accès à tuyau nommé.
Précision du flotteur
Le type de float64 Go fournit environ 15 à 16 chiffres décimaux significatifs. Les SQL Server decimal et numeric types peuvent représenter jusqu'à 38 chiffres de précision. Lors du balayage decimal/numericde colonnes dans float64, une perte de précision peut survenir pour des valeurs de plus de 15 chiffres significatifs.
Solution de contournement : Scannez decimal/numericles colonnes dans string une bibliothèque décimale tierce telle que shopspring/decimal (github.com/shopspring/decimal) ou cockroachdb/apd (github.com/cockroachdb/apd) pour des calculs précis. Pour les motifs, voir Mappages de types de données.