I said: > When data model changes occur, you've got to > change dependent SQL in every relevant module.
Frans replies: > using procs isn't going to change this. If you add a field to a > table, your insert proc needs to accept that... True, and for Updates as well. But SELECTs far outnumber those (in my experience). > and all call code needs to be updated as well. I'm not sure what you mean by "all call code". As I read it, this is not true. Typical changes are "widen this string", "add a criterion to a WHERE clause". Neither of them have ANY effect on the caller. Even adding a column doesn't TYPICALLY force a change in our server-side code; ADO.Net is perfectly happy to silently add the new column into the dataset. However, the client still needs rebuilding to consume the data (assuming there was some reason you wanted it in the first place). Also, I've experienced much-delayed build errors when auto-generated methods like AddRow() in typed datasets are re-generated weeks after the initial change, and it's hard to remember that there had been a change to cause it. Our level of re-use is generally at the web service level, not in the DB. That is, we potentially have multiple SPs that perform the same or similar tasks. Any one SP only needs to guarantee its own external interface. This alleviates some pressure on our dependency-tracking problems. The thing is, it's a lot easier to discover dependencies in the DB because, if nothing else, you can easily dump a CREATE script for the whole schema and text-search through it. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
