Anything better than TSQL?

Recently I've been doing a good amount TSQL programming, and I think
it is a phenomenal data query language. However, in my view, it may be a
little too much so, because with all of its control constructs and additions
to SQL92, it almost gives the appearance of and certainly gives the
opportunity to be used as a general purpose programming language. However, a
s
a programming language, it is not very good at all. Although it is certainly
capable of doing most any general purpose task (and almost certainly turing
complete), it is decades behind any major language today (again, I speak
regarding its consideration as a general purpose programming language).
Now to the question.
Recently, I've been doing a good deal of business logic that, for legacy and
practical reasons is implemented in TSQL.
Is there a way to use a more capable language in perhaps another layer atop
SQL Server while still retaining the local access to all of the database
contents?
Maybe embedded TSQL in C# or vice versa?
I know that such a thing is considered unneccessary, and that
the standard response would probably be 'redesign your database' or
'build some middleware thing', but out of curiosity I have to ask if there
is another option.
Thanks for your input,
KyleSQL Server 2005 does exactly what you want. Too bad it's still in beta.
"Kyle" <Kyle@.discussions.microsoft.com> wrote in message
news:F04F95F9-EFCE-4300-BD3F-8ED1A82D3016@.microsoft.com...
> Recently I've been doing a good amount TSQL programming, and I think
> it is a phenomenal data query language. However, in my view, it may be a
> little too much so, because with all of its control constructs and
additions
> to SQL92, it almost gives the appearance of and certainly gives the
> opportunity to be used as a general purpose programming language. However,
as
> a programming language, it is not very good at all. Although it is
certainly
> capable of doing most any general purpose task (and almost certainly
turing
> complete), it is decades behind any major language today (again, I speak
> regarding its consideration as a general purpose programming language).
> Now to the question.
> Recently, I've been doing a good deal of business logic that, for legacy
and
> practical reasons is implemented in TSQL.
> Is there a way to use a more capable language in perhaps another layer
atop
> SQL Server while still retaining the local access to all of the database
> contents?
> Maybe embedded TSQL in C# or vice versa?
> I know that such a thing is considered unneccessary, and that
> the standard response would probably be 'redesign your database' or
> 'build some middleware thing', but out of curiosity I have to ask if there
> is another option.
> Thanks for your input,
> Kyle|||...but it gives us about a year to get ready... ;)|||T-SQL is a simple one-pass compiler that was not meant for application
development. The original "rule of thumb" was never write a proc over
one page (50 lines) long.
You can embed SQL into any of the ANSI X3J languages, but we also have
the SQL/PSM Standard if you want a language designed to be used with
SQL.|||you can build COM components and use them within TSQL using sp_OACreate whic
h
is maybe what you could look into. You could also create extended stored
procedures written in C, C++ although these run in the same address space as
SQL Server so a crash inside one of these procedures can bring down the
server. This fact alone usually makes my choice simple - create COM objects
in VB and most of the programming world will understand it and because it
will run in a seperate address space to SQL Server - the component won't
bring down the server.
regards,
Mark Baekdal
http://www.dbghost.com
http://www.innovartis.co.uk
+44 (0)208 241 1762
Build, Comparison and Synchronization from Source Control = Database change
management for SQL Server
"Kyle" wrote:

> Recently I've been doing a good amount TSQL programming, and I think
> it is a phenomenal data query language. However, in my view, it may be a
> little too much so, because with all of its control constructs and additio
ns
> to SQL92, it almost gives the appearance of and certainly gives the
> opportunity to be used as a general purpose programming language. However,
as
> a programming language, it is not very good at all. Although it is certain
ly
> capable of doing most any general purpose task (and almost certainly turin
g
> complete), it is decades behind any major language today (again, I speak
> regarding its consideration as a general purpose programming language).
> Now to the question.
> Recently, I've been doing a good deal of business logic that, for legacy a
nd
> practical reasons is implemented in TSQL.
> Is there a way to use a more capable language in perhaps another layer ato
p
> SQL Server while still retaining the local access to all of the database
> contents?
> Maybe embedded TSQL in C# or vice versa?
> I know that such a thing is considered unneccessary, and that
> the standard response would probably be 'redesign your database' or
> 'build some middleware thing', but out of curiosity I have to ask if there
> is another option.
> Thanks for your input,
> Kyle|||I would shy away from using COM components in SQL. My experience using them
is
that they are slow and can cause problems if designed to be free-threaded
instead of single threaded apartment. For now, your best bet is to continue
using T-SQL or...
SQL 2005 will really provide what you want. It will allow for procedures in
C#
(or VB.NET) inside of SQL Server. Microsoft has announced the release of SQL
2005 on November 9th this year.
Thomas
"Kyle" <Kyle@.discussions.microsoft.com> wrote in message
news:F04F95F9-EFCE-4300-BD3F-8ED1A82D3016@.microsoft.com...
> Recently I've been doing a good amount TSQL programming, and I think
> it is a phenomenal data query language. However, in my view, it may be a
> little too much so, because with all of its control constructs and additio
ns
> to SQL92, it almost gives the appearance of and certainly gives the
> opportunity to be used as a general purpose programming language. However,
as
> a programming language, it is not very good at all. Although it is certain
ly
> capable of doing most any general purpose task (and almost certainly turin
g
> complete), it is decades behind any major language today (again, I speak
> regarding its consideration as a general purpose programming language).
> Now to the question.
> Recently, I've been doing a good deal of business logic that, for legacy a
nd
> practical reasons is implemented in TSQL.
> Is there a way to use a more capable language in perhaps another layer ato
p
> SQL Server while still retaining the local access to all of the database
> contents?
> Maybe embedded TSQL in C# or vice versa?
> I know that such a thing is considered unneccessary, and that
> the standard response would probably be 'redesign your database' or
> 'build some middleware thing', but out of curiosity I have to ask if there
> is another option.
> Thanks for your input,
> Kyle|||And in the real world people have to deal the situation at hand - keep it
real - we all want the budget for the next best technology but we need to
deal with the present in a realistic manner. 2005 is still not available
which is useless to people who need to deal with the present production
systems, be helpful not ignorant of the situation at hand. Can the problem
wait? Does the problem need a solution currently available?
Simple questions that ultimately will give you the path you need to follow.
when waiting is the best option it means you have to wait - your business
can wait?
when you need a solution - get it, make it work if it fits and the business
requires the function.
regards,
Mark Baekdal
http://www.dbghost.com
http://www.innovartis.co.uk
+44 (0)208 241 1762
Build, Comparison and Synchronization from Source Control = Database change
management for SQL Server
regards,
Mark Baekdal
http://www.dbghost.com
http://www.innovartis.co.uk
+44 (0)208 241 1762
Build, Comparison and Synchronization from Source Control = Database change
management for SQL Server
"Thomas Coleman" wrote:

> I would shy away from using COM components in SQL. My experience using the
m is
> that they are slow and can cause problems if designed to be free-threaded
> instead of single threaded apartment. For now, your best bet is to continu
e
> using T-SQL or...
> SQL 2005 will really provide what you want. It will allow for procedures i
n C#
> (or VB.NET) inside of SQL Server. Microsoft has announced the release of S
QL
> 2005 on November 9th this year.
>
> Thomas
>
> "Kyle" <Kyle@.discussions.microsoft.com> wrote in message
> news:F04F95F9-EFCE-4300-BD3F-8ED1A82D3016@.microsoft.com...
>
>|||There are other solutions than using a COM component in SQL. For example, yo
u
could call the COM component directly. You could use a Web Service etc.
Further, 2005 IS a viable option given that you can get a Go Live license. B
oth
of those options are better, IMO, than calling a COM component through T-SQL
. I
would put COM components called through T-SQL at the bottom of my list of
choices. There are far better solutions available.

> when you need a solution - get it, make it work if it fits and the busines
s
> requires the function.
That's fine to a point. The problem comes when that "temporary" solution bec
omes
a permanent solution. Correcting problems caused by this scenario can be a f
ar
bigger headache than doing it right the first time.
Thomas
"mark baekdal" <markbaekdal@.discussions.microsoft.com> wrote in message
news:0572C462-09E9-48D1-A4BB-A19D9BCA3599@.microsoft.com...
> And in the real world people have to deal the situation at hand - keep it
> real - we all want the budget for the next best technology but we need to
> deal with the present in a realistic manner. 2005 is still not available
> which is useless to people who need to deal with the present production
> systems, be helpful not ignorant of the situation at hand. Can the problem
> wait? Does the problem need a solution currently available?
> Simple questions that ultimately will give you the path you need to follow
.
> when waiting is the best option it means you have to wait - your business
> can wait?
> when you need a solution - get it, make it work if it fits and the busines
s
> requires the function.
>
> regards,
> Mark Baekdal
> http://www.dbghost.com
> http://www.innovartis.co.uk
> +44 (0)208 241 1762
> Build, Comparison and Synchronization from Source Control = Database chang
e
> management for SQL Server