>>Dave,
>>
>>I don't think so. If I understand correctly, Rob is talking about adding an audit trail, or tickler, or something. I don't think this is a matter of ensuring a parent record exists when a child is added. Maybe Rob could clarify for us.

>Rob,
>From my experience, it would seem that you would build these rules as Stored Procedures that would be called as part of you INSERT/UPDATE/DELETE triggers.
>
>In your example, you would write a function to create a record in table Y in your stored procedures ("AddtoY"). Then in the properties of table X, set your INSERT trigger to run the new stored procedure. Just be careful how you handle the call if there is already a function in yout INSERT trigger created by the referential integrity builder:
>
>INSERT TRIGGER: _ri_insert_x() AND AddtoY()
>
>Hope this helps you out.

Dave & Josh:

Thanks for the input - I am indeed trying to build an audit type of function where inserts into various tables are all logged in a journal type of table. While I think the 3 tier architecture really would do what I want, it is probably overkill for what I am trying to do.

Anyway, I am looking at Stored Procedures and defining insert triggers. Is there any way to handle returning a code (i.e. 0=OK, 1=INVALID_DATA, etc) from AddToY() rather then .T. if added and .F. if not ? This may seem weird, but because I am doing lookups and inserts in the AddToY() function, I want to determine if the function failed because the lookup failed or if the insert failed. I know I can define the INSERT TRIGGER as __ri_insert_x() AND AddToY() = ADD_REC_OK, and the trigger will return .T. if AddToY() returned a certain value. The question is how do I return the result of AddToY() to the object that called the INSERT in the first place ?

Sorry if this ambigous ...
Thanks again
Rob