Étant donné que ce code a été utilisé à l'origine avec des procédures stockées étendues, il semble qu'il s'agisse de code non managé. Les bogues dans le code non géré peuvent facilement planter votre processus.
L'intégration CLR est beaucoup plus robuste que les procédures stockées étendues, mais le code s'exécute toujours dans le processus, de sorte que des erreurs peuvent arrêter ou corrompre SQL Server. (À titre de comparaison, en théorie, une routine SAFE CLR ne pourra pas corrompre SQL Server, même si cela peut causer des problèmes qui réduisent la disponibilité de votre serveur sans totalement arrêter SQL Server.)
Fondamentalement, les seules façons de ne pas planter SQL Server dans ce scénario sont :
- Évitez d'utiliser la fonctionnalité qui plante.
- Corrigez le code bogué.
- Exécutez le code dans un processus séparé (lancez un exécutable, appelez un service Windows, appelez un service Web, etc.). Vous pouvez écrire une DLL .NET managée pour effectuer cette interaction. Très probablement, vous devrez toujours le charger UNSAFE, mais - s'il est écrit correctement - en réalité, il peut être assez sûr.
