Francisco H Tapia
my.lists at verizon.net
Wed Jun 30 18:42:32 CDT 2004
I hear what you're saying Shamil, but coding is coding at any layer. So even with less resources, ie, .net or c# programmers, code must still be altered even if not at the sql server, but at the gui or webservice layer. These statements don't make as much sense to me as just modifying the logic at the source. coding w/ .net components in your sproc doesn't make them dynamic sql, it's like coding .COM objects in your sproc you can do it via sp_OAxxx but these are limited to sysadmin roles because of the major security risk involved. no offense either to you or to the article you posted, it's a good article, I just don't agree that column names justify dynamic sql. There are otherways of working output at the gui level if that is ultra imporant. Shamil Salakhetdinov wrote On 6/30/2004 3:56 PM: >Arthur, > >Just a philosopical opinion/point of view: > >Database-centered programming for nowaday businesses are becoming more >and more dynamic and constantly changing.... >The SPs are like a "chiseled in stone" stuff. >And dynamic SQL is an amorphic matter, flexibly and smoothly adapting to >constantly changing businesses and their business rules. >Please take into consideration this fact: "chiseled in stone" DLL-Hell >producing COM interfaces are being substituted with .NET Framework >flexible architecture... >IMHO the similar tendence is starting to appear itself more and more >apparently in data(base) layer programming. >Here is why Application Roles (see BOL) were introduced. >Here is why Youkon will support smooth integration with C#/VB.NET/... >extended SPs which in turn will (I guess) work heavily with dynamic >SQL... > >And as far as I see metadata-based data access and data >integrity/business rules verification/support are also becoming more and >more popular - and this is what is needed for the modern small and >middle size businesses: they urge for the broad automation of their >businesses because of economical and other reasons but they don't have >enough resources to finance design and development and then constant >redesign and code rewriting/refactoring... > >And of course I'm not talking about "SPs must die" - as usual solution >is somewhere in between and is a balance of many interests but for sure >dynamic SQL's role isn't that narrow as described in >http://www.sqlservercentral.com/columnists/rmarda/whendynamicsqlisuseful_printversion.asp - >the fact is that most of these samples look obsolete because they can be >rewritten IMO using UDFs, XML (OpenXML) - i.e.using SPs but without EXEC >I think! :) > >Just my pair of roubles, >Sorry in advance if I did miss the subject of this thread, >Shamil > >-- >e-mail: shamil at smsconsulting.spb.ru >Web: http://smsconsulting.spb.ru/shamil_s > >----- Original Message ----- >From: "Arthur Fuller" <artful at rogers.com> >To: <dba-sqlserver at databaseadvisors.com> >Sent: Wednesday, June 30, 2004 6:57 PM >Subject: RE: [dba-SQLServer] Difference between views and queries > > > > >>Good example, and good reasoning, and I agree that dynamic SQL is >> >> >never > > >>out of the question. What I intended to write is that more often than >>not, dynamic SQL is the lazy way out of thinking carefully about >> >> >sprocs. > > >>Most of the time it is unnecessary and costly in terms of performance >>and front-end code; some of the time, there is no other way. >> >>Arthur >> -- -Francisco