> From: Moderated discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED] On Behalf Of J. Merrill > Sent: Thursday, February 19, 2004 4:49 PM > > It is uncommon for an application (using current MS technologies) to be > able to handle changes to the columns returned by SELECT * without some > kind of "hard error" that crashes the app, rendering it useless until > modified and redeployed.
True. Very true. It is also just as true that some types of database changes like a column split will ruin any code (view, sproc, or, heavens forbid, app-layer code) that works directly from a SELECT [commalist]. Basically, all application layer code should go through either views or sprocs (and should never go to tables directly for precisely the reasons we talk about). Views and some sprocs will be intimately tied to the table structure and certain changes in the physical structure will not save SELECT * or SELECT [commalist] views and sprocs. You either have to change to continue to provide the old fields, or change to include the new fields. SELECT [commalist] might save some work in a proper app layer (one without its own hard-coded SELECTs), but there is still potentially a lot of work in the DB layer. To a guy like me that often wears multiple hats, one vs the other is meaningless. That's my point. And, my last comment. I swear. :) :) _________________________________ Paul Tiseo, Systems Programmer Research Computing Facility Mayo Clinic Jacksonville, Griffin 371 [EMAIL PROTECTED] =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
