>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
>

Hello, Henry. I just come back.
After read through whole thread, this question will be one of your concern.
Good question! :)

Maintain the project over a period of time, which easier.

DBC gives a standard way to store:
Views to stored some SQL calculation field etc.
One great Benefit is very easy on reports.

e.g. For same Quote Sheet Data, Once you make the view.
You can use it in any report format.

Now, if one of the Client-Request Quote sheet require:
# of item on 40' container..
You only add a calculate field on that view..
All your quote report can put this new field as well..

Maintain on add, change. Fast and easy.
Of course, Formal. IF a new programmer comes, he can follow it with std. way

But Maintain on Delete need to do correctly!!!
On View Designer, if wonder there is a field request from table which
DOES NOT EXIST.. it will blank everything!!!(I hate this default action)
In other words, you lose the view if you direct delete field from table.

To delete field from table or RENAME field from table:
First thing must do:
- remove corresponding field from all views

Then you can update the forms, reports, labels, or tables as you wish.
Of cos, you need update all corresponding to make it bug-free.

DBC is the backbone of the project,
if you did it wrongly, the lose may be large.

So, What is the best way to maintain it easier.
Make a simple excel worksheet to carry:

Table/Field        ViewName1 ViewName2 ...
Customer.CustName    use      not use  ...
...

Once you need to maintain, check the worksheet and do it with missing.


Well, how about Free table, is it really benefit on maintain?
I can say it would NOT serious on the maintain step.
but because it is informal, you can to check everywhere in your application.
Where I have put some SQL cursor/tmp table for report.
The maintain cost will be large, but very safety, the list of field will not gone.
Surely, if the developer change job, another progr need waste more time to study well.


In General, I would put all tables into DBC if the table give
fix relationship on other tables and it is for data entry.

For those using one or two times and do not give relationship
with others, it is quite meaningless to put it in DBC.
(wasting the loading time)

---

Above is only the maintain job on developer PC.
On Client PC update, you need to setup a prg to import all data from client current Table into your new DBC structure and replace everything after all:

Including:
- .DBC .DCX .DCT (DBC files)
- .DBF .CDX .FPT (new structure table)
- .EXE
- .FRX .FRT (Report if needed)

But for free table, it can use same way as DBC,
or you can use another prg to add/remove field directly on client table..
This part of update is really piece of cake.

Note:Remember to backup Client folder before take any action..
Data is more important.


>>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