Rob,

The latest thinking in application design is 3-tier architecture. In this architecture you have the presentation layer (the user interface), the business logic layer (all those rules like create a record in Y when X is updated), and the data layer. The data layer enforces data integrity rules like unique primary keys and referential integrity.

Of course, you should physically separate these layers. The Microsoft way to do this would be to write the presentation layer in VFP, VB, or IE4, the business logic layer using COM objects (which you can write in VFP) running under Microsoft Transaction Server (MTS), and the data layer using SQL Server. Of course, this may be ridiculous overkill for what you're trying to do now. Looking ahead, however, it may be best to adopt that approach now as you described. That is, move the business logic to the data objects. This will make it much easier to move to a 2-tier approach using a different back-end, then a 3-tier approach. For the latter, you would just remove your data objects from the front end and make them COM servers.

If you think you may need to move your solution to 3-tier architecture in the future, it may not be a bad idea to learn about MTS now. It will give you some ideas on how to create the data objects in a way that will work well in 3-tier.

Hmmm. I guess a long post deserves a long answer. Hope this helps.

>I am in the design stage of an app and have developed a series of "rules" regarding the inserting/updating/deleting of data that I could use some advice on. I originally thought to store these rules in DBC stored procedures, which works for simple checks like don't allow deletes if status <> OPEN.
>
>The problem is that some of my rules are more complex, like "Every time a record is inserted into table X, create a record in table Y". This usually will involve taking a value from the new record in X, doing a lookup in a support table and then inserting a record in Y with the data returned from the support table.
>
>SOOO, my question is whether a stored procedure is the right place to do this, or should I handle this in the objects that manage the data ? I had thought stored procedures would make it easier and enforce consistancy, but believe I may be creating a monster. Any comments/thoughts would be appreciated