Generally, I would use stored procedures for all things relating to the referential integrity of the database - primary keys, foreign key constraints, etc. This way if my DB ever gets hit by an external source I can at least guarantee some consistency. But I make sure that whatever I put in there stands entirely on its own. The one frustrating thing that I see sometimes is when developers put dependencies on their applications in stored procedures - this makes it impossible to use the app from outside of the application environment.

Usually I express business logic in middle-tier objects.

>>Hi all,
>>
>>What is the consensus out there (or the divergence? <g>) as regards
>>using Stored Procedures vs having the code as part of one's
>>program/form ?
>>
>>Thanks in advance.
>>
>>Michel Creppy.
>
>I like using Stored Procedures for processes (such as calculating the unique key id for a table, etc...) that will be used uniformly in a DBC especially if you have multiple applications hitting or using the same DBC.
>
>For me as a general guide, if it's universal for that DBC put it in the Stored Procedures. If it's application specific, keep it in the application. If you're using Classes and it's specific to the Class, put it in the Class.
>
>Tom