Hi
How your stored procedures are constructed will depend on how you wish to
use them!! If there is a requirement to validate data on it's own (e.g in an
event for a given field) then you should write a single procedure that does
that, of course you would need to re-validate it before committing the data
to the database. This may use the same procedures, but then if you can
combine validation it will be more efficient. Large amounts of code in your
procedures may make it more likely to be recompiled, therefore splitting
them up may reduce that. There is also the issue of maintainance, which is
more difficult if you use a less modular approach to designing your stored
procedures.
HTH
John
"Jake Jessup" <wa*********@hotmail.com> wrote in message
news:Jb*******************@newssvr29.news.prodigy. com...
I'm a newbie when it comes to the SQL Server side of things. I've been
doing Access on and off for years.
I've got a form that is the main point of entry for all data.
As a matter of technique, should I use one stored procedure to validate
data (testing for uniqueness mostly) then another one to actually write the
data to the tables?
Does it make a difference one way or another to the performance?
Do I gain any flexibility in my app dong it that way (Access Data
Project)?
Your help is appreciated.
--Jake
