Re: Setting a Column Value on Insert

fox@acdlab.garnet.ru ("Igor I. Lisyansky") wrote: :Hello! : :Bob Carts wrote : :4) I would like to avoid forcing the application coders to do their insert :via a stored procedure if possible. : :Any ideas? : :Sorry, IMHO, limiting the external interfaces of the database application to stored procedures only or :at least mostly has some definite advantages (especially for OLTP applications): :1) It's very portable and works a similar way in different DBMS. It's the first time I have heard this. Do you have an easy way to port between PL/SQL, SPL and the Sybase and Microsoft stored procedure languages? :2) It allows the extreme control over data consistency. It does, but so does intelligent coding. :3) It allows to hide the tables structure and even change them not affecting the applications (not :always, surely). You can hide the table structure, but the part on changing them isn't much different if you code your application well. If you do you will also not see the table structure in any other part of your code than the functions or methods used for table access. That makes for equally simple "front end" coding. In my opinion it'll be even simpler as the tools for maintaing program code are generally better than those for maintaining a combination of program code and stored procedures. :4) It seriously simplifies the front-end coding May be, but does it make the whole application simpler, including the stored procedures? :5) Making the tables inaccessible directly increases the security and protection against the incorrect :operations (views aren't a comprehensive solution here). This is a true advantage. :6) In most DBMS, stored procedures work faster. They often don't if they are simple. :7) In some DBMS, triggers are less convenient then procedures, and require more coding and 'Clipboard :instead of Procedures' programming technique. They can be combined. :8) Procedural code is far more readable and easy to maintain then complex queries expressed in declarative :terms. You mean procedural implementations of what would otherwise be done in a complex sql statement? In that case it's often true, but that advantage is of course the same using sql in a regular program. Again there is no big difference (if any at all) to maintenance as you would have one function (or method) implementing essentially the same as one procedure. I don't say you shouldn't use stored procedures. We use them for several purposes. I would however be very carefull about using them as extensively as seems to be implied here. Nils.Myklebust@idg.no NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway My opinions are those of my company The Informix FAQ is at http://www.iiug.org