Ne partez pas du principe qu'un thread managé est un thread Win32 ; ce peut être une fibre. Le CLR exécutera les threads ...

Ne partez pas du principe qu'un thread managé est un thread Win32 ; ce peut être une fibre. Le CLR exécutera les threads managés en tant que fibres sur les threads réels appartenant à SQL Server. Ces threads seront partagés sur plusieurs AppDomains ainsi que dans des bases de données dans le processus SQL Server. Le stockage local des threads managés fonctionnera mais vous ne pourrez pas procéder à un stockage local des threads non managés ou tenter de réexécuter le code sur le système d'exploitation actuel. Ne modifiez aucun paramètre comme, par exemple, les paramètres régionaux du thread. N'appelez pas CreateCriticalSection ou CreateMutex par le biais de P/Invoke puisqu'ils exigent que le thread qui accède à un verrou quitte également le verrou. Ce cas étant impossible avec l'utilisation de fibres, les sections critiques et les mutex Win32 n'auront aucune utilité dans SQL.
Vous pourrez en toute sécurité exploiter la majeure partie de l'état d'un objet System.Thread managé, notamment le stockage local des threads managés et la culture d'interface utilisateur actuelle du thread. Cependant, pour des raisons de modèle de programmation, vous ne pourrez pas modifier la culture actuelle d'un thread lors de l'exécution de SQL (vous devrez pour cela bénéficier d'une nouvelle autorisation).