>>>>>HI
>>>>>
>>>>>I have a c# CLR that I'm using to decrypt bank sort codes and account number.
>>>>>
>>>>>I've has an error that caused SQL to restart
>>>>>
>>>>>A fatal error occurred in the .NET Framework common language runtime. SQL Server is shutting down. If the error recurs after the server is restarted, contact Customer Support
>>>>>
>>>>>This seems to occur when I use the CLR in a table update rather than just decrypting one row.
>>>>>
>>>>>so
>>>>>
>>>>> update integra_live.dbo.xmasall set sortcode_decrypt = dbo.fn_RMB_RemoveCharacters(dbo.fn_RMB_bank_decrypt([Sort Code],@decrypt_key), '^0123456789') where [DD reference] = 'RWM000196'
>>>>>
>>>>>works
>>>>>
>>>>>and
>>>>>
>>>>> update integra_live.dbo.xmasall set sortcode_decrypt = dbo.fn_RMB_RemoveCharacters(dbo.fn_RMB_bank_decrypt([Sort Code],@decrypt_key), '^0123456789')
>>>>>
>>>>>fails
>>>>>
>>>>>any ideas why there should be this differnce
>>>>>
>>>>>as an extra confusion bith statements work perfectly on my development server.
>>>>
>>>>Is your development machine running against the same DB ?
>>>>If not then I'd guess Naomi is right : bad data (or your function/s not handling some variation correctly)
>>>
>>>I don't think so. The data is an imported csv file. Imported into a temdb table and I've imported the same file onto both machines.
>>
>>Hmm. So same data but different instance of SQLServer ? Maybe some difference there causing the problem?
>>Also see a few references to this error occurring from high memory use - might be worth checking whether the C# code is being efficient in releasing same - or tweak the memory allocation for SQL....
>
>Hi Viv
>
>The c# code is that CLR we discussed a while ago. How would I check it was being efficient and how would I change the memory allocation for SQL ? I do wonder if its some sort of resource problem as maybe the table update using the CLR creates a lot of threads simultanously. I don't know why this is not a problem on the XP development box.

I only vaguely remember the CLR discussion. I guess just make sure that Dispose() gets called on anything implementing IDisposable(). I thought of mentioning a possible threading issue but I've no idea how (or if) SQL uses threading with the CLR.

I *think* that you can set the maximum memory available to SQL so reducing it should free up more for the CLR. But I don't know enough SQL to be sure of this and, IAC, it might only mask the problem.

Can you monitor memory usage to see if the problem does lie in that direction ?