>errr, here you might be wrong though. The client apps need to be addressed as well. For example when inserting a record, you need to change the call to the stored procedure to change the number of parameters. If you've got a few dozen installation of one database app, you don't wan't to be bothered with incompatible versions of SPs combined with an incompatible client app version.
>
>The case is however that you don't want to maintain a huge number of inflexible SPs. If something is wrong, it is much harder to debug what is going wrong than within your client application.
>
>Maybe, maybe not. If you have a 'thin' or 'smart client', you may need to make a change on the application server, which is just one change in one location. And even if the change 'does' ripple all the way down to the client level [e.g. a new entry field that maps to a new db column], the new click-once capabilities in VS2005 make the deployments pretty painless.

>Bottom line, there 'are' capabilities in the tools to make these types of changes routine and pretty painless.

There might be ways to ease the pain, but the big problem of those 'solutions' is that they are pretty short scoped and seldomly general applicable. If .NET has a workarround for it, it does not mean that handling the problem in Java is that easy.

Even worse, is that people don't see the flaw in the entire concept. What is it that you want to achieve with SPs ??

- Security? You could probably do the same with role based security and views, though I can see certain applications could be helped with one static interface to the data. But this really is the exception rather than a commonality.
- Performance? In most cases there is no measurable difference as both SPT and SP execution plans are cached. However since the inflexible nature of SPs you might get screwed when you want to do be smart and save you writing several SPs and use parameters to influence the where clause of the SQL statement because in sutch cases the plan is not refreshed and givin the new values of the parameters your execution plan might cause your query to be very slow. (happened to me a couple of times which forced me to recompile it at every execute)
- Saves maintenance? Bogus, This probably is the worst case. When maintaining the database things might be a total nightmare.

SPs at a time were a good idea, because on older hardware you could save some significant time by precompiling the SQL statements. However they have lost much of their value along the way.

Walter,