sqlclr

I want to write a service (probably in c#) that monitors a database table. When a record is inserted into the table I want the service to grab the newly inserted data, and perform some complex business logic with it (too complex for TSQL). One option is to have the service periodically check the table to see if new records have been inserted. The problem with doing it that way is that I want the service to know about the inserts as soon as they happen, and I don't want to kill the database performance. Doing a little research, it seems like maybe writing a CLR trigger could do the job. I could

I'm trying to debug a CLR based StoredProcedure in Visual Studio 2012 RTM. I have a Sql Database Project. When I try to debug my script file using RightClick -> Execute with debugger it pop ups a warning about harmfulness of attaching a process and when I accept it just say that : Unable to debug .Net Code. Could not attach to SQL Server process on 'Devserver'. I've done many different things : I've added my domain user to sysadmin SQL Server Role. I've run MSVSMON.EXE on the Remote Server and set up it's permissions. I've configured Visual Studio Project's ConnectionString in Properties pane.

SQL Server's hashing function HASHBYTES has an input limit of 8000 bytes. How do you hash larger strings? You could hash 8k (or 4k or 2k) chunks of the input and then either concatenate those hashes or hash them into a new hash value. This might get difficult though if you have to create a similar algorithm (in an external .NET app for example) to compare hashes created outside of SQL Server. Another option: Lean on SQL Server's CLR integration and perform the hashing in a .NET assembly. You could write a SQL CLR function: [Microsoft.SqlServer.Server.SqlFunction] public static SqlBinary

What advantages does SQLServer CLR offer over T-SQL? Is using .NET syntax easier than T-SQL? I see that you can define user types, but I'm not quite clear on why that's better. For example, you could define an email type and it would have a prefix property and a domain property. You could then search on domain or prefix or both. However, I don't see how that's any different from adding a couple of columns one called prefix and one called domain and searching on them individually. Maybe someone has real world reasons why this is better. I'll give one good example: CLR has a built in RegEx

We have developed an assembly for SQL Server 2008 R2. The assembly has been working for a week. The managed stored proc inside the assembly was working fine for the whole week and then it stops working. We have been seeing this problem couple times. The way to make it work again is to restart the SQL Server. Msg 10314, Level 16, State 11, Line 4 An error occurred in the Microsoft .NET Framework while trying to load assembly id 65536. The server may be running out of resources, or the assembly may not be trusted with PERMISSION_SET = EXTERNAL_ACCESS or UNSAFE. Run the query again, or check

We've got a regular (i.e. not extended) stored procedure in SQL Server 2000 that calls an external exe. That exe, in turn, loads a .dll that came from an SDK and calls some procedures from it (i.e. Init, DoStuff, Shutdown). The only reason we have this external exe thing is because we didn't want to create an extended stored procedure that would call the .dll. We believed that if the dll crashes (an unlikely event but still) then the SQL Server process will crash as well which is not what we wanted. With an external exe, only that exe would crash. Now, we're upgrading to SQL Server 2008 and