jwcolby
jwcolby at colbyconsulting.com
Wed Dec 2 12:46:09 CST 2009
Do you use it? John W. Colby www.ColbyConsulting.com Gustav Brock wrote: > Hi John et al > > Don't forget LINQPad. > > Why LINQ beats SQL: > http://www.linqpad.net/WhyLINQBeatsSQL.aspx > > /gustav > > >>>> Gustav at cactus.dk 02-12-2009 08:19 >>> > Hi John > > As I see it, that would be LINQ and ADO.NET EF (Entity Framework). Not that I have used these in a scenario even "remotely close" to yours, but the fine thing is that is performs all the plumbing behind the scene - generates the SQL for you. Critics tell that this SQL could be long-winded (= not optimized) but what do I care? If it flips 17 or 87 switches does nothing to me as long as the result is fast and precise. > > ADO.NET EF is an amazing piece of work. It is not mature but if MS continues to evolve it with the same speed as Silverlight I'm sure it will catch up. > > /gustav > > >>>> jwcolby at colbyconsulting.com 01-12-2009 23:53 >>> > As previously mentioned, over the last couple of years I have built up a set of stored procedures > which perform TSQL. I then run sets of these stored procedures to perform processes. The TSQL is > always dynamic. > > As an example a stored procedure might build a table, with boilerplate field names and data types, > but a passed in database and table name. Inside of the stored procedure I build up the correct SQL > to create the table in the database specified, with the name specified. Another stored procedure > might create in index, with boilerplate field names, but a passed in database and table name. Again > the stored procedure builds up the TSQL statement to create the index in the correct db and table. > > I already have these stored procedures debugged and working and have been using them in sets to > perform "big picture processes" for quite some time, but the whole "execute a stored procedure" > using a command object, parameter objects in a parameter array, interpreting the parameters etc just > seems so... 1950s. I feel like I am flipping switches on the front panel of a computer in a 50s > sci-fi movie as a tape reel spins madly in the background. > > Now that I am moving to C# I am wondering if this is required any more. Can C# execute TSQL > directly somehow? Can I assemble this boiler plate plus database / table kind of thing into a TSQL > statement directly in C# and then somehow tell SQL Server to execute that TSQL? I understand the > "SQL optimization" thing but it seems like (not sure here) that because the TSQL is dynamically > constructed in the stored procedure, the whole "optimization" thing goes right out the window. If I > can execute TSQL directly from C#, what can I get back? Rows affected? Error codes? And how? > > As it stands I am happily flipping switches, tape reels whirring, exporting data for address > validation. This is good, I am happy, but ... >