Hi Leland - you are obviously suggesting the use of DBC's over free tables. Which of the two are easier to maintain over a period of time (e.g. wanting to add or delete a field in a table that has been distributed to the client).

Appreciate your valuable input.

- Ravi

>Hi,
>
>With tables in a DBC you can establish presentent relationships which in turn allow for referential integrity checking between the parent tables and the clild tables. RI is enforced even outside an application like when adding or deleting records in browse mode. Of course you must have your tables properly normalized. Also, a DBC is necessary to use the BEGIN TRANSACTION. If all transaction update successfully with the tableupdate() an END TRANSACTION can be issued. Otherwise transactions can be ROLLEDBACK. This protects tables from curruption as transactions not updated are rolled back even when a client computer locks up or an entire network goes down due to power failure. Also with a DBC you can use other features like input masks or formatting of fields for your tables that will be in effect even when using a table outside an application in browse mode. There are probably many other advantages to using DBC but these come to mind right now.
>
>Referential integrity adds some overhead to an application but in my opinion its worth it. In my application I delete the trigger when it is not needed and then set it back up after perfroming some processes. For example my application has a process that inserts zero in an amount field to set beginning balances in a table back to zero. To avoid unnecessarily executing RI for each transaction that has a zero inserted, I remove the insert trigger and then reinstate it after the process has finished. The ability to remove triggers and then reinstate them programmically as the application executes allows code to be twiked for optimal performance.
>
>Leland