Re: User defined types command parameter types
- From: "Mary Chipman [MSFT]" <mchip@xxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 27 Aug 2005 20:38:52 -0400
The reason you have to do it in two places is because you have two
different code bases running in two separate processes. ADO.NET is
simply the pipeline passing information from your client application
written in C# to the database where your stored procedures are written
in T-SQL. Think of it as messaging, where your app sends a message to
the server telling it what it wants done. If the instructions in your
message aren't accurate, then the server isn't going to be able to
provide the results you expect.
SQLS 2005 hosting the CLR isn't going to make any difference in this
regard. T-SQL is still used under the covers for data access, and if
all your application does is basic data access, then you probably
aren't going to need or want SQL CLR. The reason for the CLR isn't to
make coding clients easier, it's to be able to have complex
computational code executing on the server in a compiled language. For
example, an operation doing calculations that would take 3 pages of
T-SQL code can be done in a few lines of code by taking advantage of
the BCL and be far more performant, executing in proc rather than as
interpreted (T-SQL). So even if you do end up taking advantage of the
CLR inside of SQLS, your client application will still be running
*outside* of the server. Waiting for future versions isn't going to
change the basic fact that your client code is executing in a
completely separate process which only communicates with the server
through the conduit of ADO.NET. So the need to specify parameters on
both sides of the pipe isn't going away any time soon.
--Mary
On Fri, 26 Aug 2005 11:43:28 -0700, "Mike"
<Mike@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>Hi Mary,
>
>That's a good point and you are right this is design time issue not a run
>time issue. However, having the type defined in one place makes changes to
>the code much easier to make. The round trip issue you referenced could be
>avoided if Visual Studio was more tightly integrated with SQL server. Then it
>would only update the type information at compile time. In general, I would
>like to see better integration of stored procedures and application code. I
>would like to be able to call a stored procedure the same way I call any C#
>function. I do not like having to writing all the plumbing code that is
>currently required to call stored procedures. Why should have to define
>stored procedure parameters in two places? I don't do that with methods I
>write in C#.
>
>I know that the new version of SQL Server takes a step in that direction by
>building the CLR into SQL Server. I hope following version will continue that
>direction.
>
>Thank you for your efforts to help. I think I will just have to be patient
>and wait for newer versions of SQL Server and .Net.
>
>Thanks,
>Mike
.
- Follow-Ups:
- References:
- User defined types command parameter types
- From: Mike
- Re: User defined types command parameter types
- From: Mary Chipman [MSFT]
- Re: User defined types command parameter types
- From: Mike
- Re: User defined types command parameter types
- From: Mary Chipman [MSFT]
- Re: User defined types command parameter types
- From: Mike
- User defined types command parameter types
- Prev by Date: Re: How to join two tables.
- Next by Date: Re: User defined types command parameter types
- Previous by thread: Re: User defined types command parameter types
- Next by thread: Re: User defined types command parameter types
- Index(es):
Relevant Pages
|
