SQL CLR Library , SQLCLR , CLR Routines , CLR Library , SQL Server CLR , Bulk Export , Regular Expressions , HTML Export , Generate Insert Statements , Median , Automation , RegEx 2024-12-22 11-58
SQL# / SQLsharp                   SQL #         Expanding the
capabilities of T-SQL
       Home       Features       Benefits       F.A.Q.       Contact Us 
     Full Version       Free Version       Documentation 
❗❗ Version 4.0 Announcement ❗❗
  SQL CLR Library , SQLCLR , CLR Routines , CLR Library , SQL Server CLR , Bulk Export , Regular Expressions , HTML Export , Generate Insert Statements , Median , Automation , RegEx

You have the task of doing somewhat complex operations at the database level, right?
Right! We all do.

Putting the debate regarding business logic in the database vs. the application aside, there are times when no matter what the answer to that question is, doing things at the database level just makes more sense, right?
Right! Let's face it, it's a reality. Not to be abused, but sometimes it just needs to be.

So you have heard about the CLR and .NET integration feature (starting with Microsoft SQL Server 2005), but are not quite sure what it means or what it can do, right?
Right! It's new, it's different, and there have been some misconceptions. The CLR does indeed provide a wondeful opporuntity to add even more powerful programming into Stored Procedures and User-Defined Functions on top of the new commands in T-SQL.

So you have a project to do and have been given plenty of time to research yet another new technology, right?
Yeah, right! As if that happens. As a database programmer, unless you are already a developer who has been tasked with doing the database work, chances are you don't have time to learn C# or VB.NET just to find out if this new CLR and .NET integration will be of help to you. And if you are a developer who knows C#, VB.NET, or Visual C++, how much time do you want to spend messing with creating utilities?

And what about the debate regarding when is it appropriate to use the CLR vs. when you should stick with T-SQL?
By exposing the most commonly needed and useful aspects of .NET and the CLR you can now do most of your work in T-SQL (which you are already comfortable with) and get the best of both worlds. Yes, you CAN have your cake and eat it, too. Thanks to SQL# (SQLsharp)!

And why should you spend hundreds dollars on Visual Studio just so you can use it once to expose the Regex.Match method?
Thanks to SQL# you don't have to. All that and so much more is already available, right now in SQL#.

That's right folks, SQL# will help cure your T-SQL blues.

Step right up and grab some of this revitalizing tonic for SQL Server 2005 (and beyond) Stored Procedures and User-Defined Functions.

SQL# is all you need for more power and more flexible T-SQL coding.

SQL# is a CLR library of useful functions that expand your ability to do real programming at the database level.

SQL# is simple to install and simple to use, yet will enable you to write SQL code that is far from simple.

SQL# is so easy and yet so useful that you will soon wonder how you survived without it!

But seriously now, consider this:

SQL# is an extensive library of useful functions to help you code more powerful SQL Stored Procedures and User-Defined Functions. For too long now T-SQL has not given the SQL programmer enough flexibility to code complex logic, at least not without going through the pain of creating a DLL and registering it as an Extended Stored Procedure (xp):

In previous versions of SQL Server, developers could extend SQL Server functionality by writing extended stored procedures. Writing high-quality extended stored procedures requires a strong knowledge of the Open Data Services (ODS) library and the poorly documented C-style Extended Stored Procedure API. Anyone who's ever attempted the old style of extended stored procedure programming can tell you it's a complex undertaking, where a single misstep can easily result in memory leaks and/or corruption of the SQL Server process space. Also the threading model used by extended stored procedures requires SQL Server to rely on the operating system to control threading and concurrency. This can also lead to issues, such as unresponsiveness of extended stored procedure code.

Earlier SQL Server releases allowed you to create OLE Automation server objects via the sp_OACreate stored procedure. Creating OLE Automation servers can be just as complex as extended stored procedure programming (if not more so). The sp_OACreate method is also notorious for memory leaks.

(Pro T-SQL 2005 Programmers Guide, Michael Coles, 2007, Apress, p.343)

But now, FINALLY, SQL# (SQLsharp) gives the T-SQL programmer and SQL Server DBA the programatic tools that previously only application developers had at their disposal. It wasn't fair that application developers had so many commands to use and yet SQL developers had but a few and had to spend too much time use those few commands to create functions to emulate the commands available in real programming languages. SQL# evens the playing-field by giving T-SQL programmers what we have been wanting for so long now. SQL# provides most of the commonly used, empowering, and time-saving commands available in the .NET languages and even some custom utilities to make life easier. So stop wasting time recreating the wheel and writing that "split" function that thousands of SQL DBAs and programmers have done thousands of times before and start focusing on the business logic that is the your true objective.

SQL CLR Library , CLR Routines , CLR Library , SQL Server CLR , Bulk Export , Regular Expressions , HTML Export , Generate Insert Statements 2024-12-22 11-58