>Peter:
>
>Its a very interesting discussion, I can see what you are telling me, but on some occasions, I am lost (but thats because I am relatively inexperienced). To quote you:
>
>"Henry, please note that I am talking theoretically only because I just don't use the DBC at all, so others may have very different opinions or even shoot mine. For that matter, I too am interested in what others have to say ...""
>
>So, if you don;t use DBC, what do you use, simply free tables?
>
>Thank you.
>
>- Ravi

Yes.
But note the definition of a "free table"; this is about tables not hung in a DBC. Now what is an Oracle table ? according to this definition "free", but that is nonsense. What is important though, is that an Oracle table won't be in a DBC ever, but a cursor for it can.

Peter


>
>
>>>Thank you Peter. A ton of knowledge there. What then is the purpose of free tables if dbc or more than 1 dbc's can provide solutions?
>>>
>>>Appreciate your assistance. Thanks again
>>>
>>>- Ravi
>>
>>
>>Henry,
>>
>>Firstly, free tables existed earlier than the DBC; the DBC was introduced in Visual FoxPro, and the free tables exist from DBaseI (I hope I say this right). Further, free tables are standardized, and the VFP Database (DBC) is not at all. Just like the indexes are not (hence DBase, Clipper, Fox have all incompatible indexes). Now look at it form this "standards" point of view : a dbf is standard, and all on top is not because all xBase manufacturers have their benefits out of the redundant stuff like index and VFPs' DBC (btw, VFP's dbf is not completely standard anymore too).
>>
>>Now the DBC is on top of the free tables, and without free tables your app won't exist. IOW, without tables it won't. So, the DBC is a means of storing definitions "around" the tables, like Views, indexes etc. That's whay you could do that yourself too, as long as you have some means of storing it.
>>
>>According to the phenomenon "database", it is IMHO some surrogate means of connecting a set of free tables to you app, and/or in the mean time have another set of Views etc. It could be benificial, but in the end I'm just not sure about this. This has to do with the remote DBMS, which just as well could provide the database for your app, and the "free tables" are somewhere else now. However, all will be shown to your app via cursors / views etc., and ... they could be in a DBC again. Hmm.
>>Now thinking of DataSessions, this is just another means of "connecting" to a database, though it was not invented for that. And, I suppose per DataSession you could have another set of DBC's or better : per DataSession you can have another Database (DBC - definition) active. Can you follow it ?
>>
>>In the very end (and IMO) a DBC can be (should be) used to get a definition of Views in with "one command" (Set Database To), and not to get a set of database-tables (though it just as well could for native VFP tables).
>>
>>Henry, please note that I am talking theoretically only because I just don't use the DBC at all, so others may have very different opinions or even shoot mine. For that matter, I too am interested in what others have to say ...
>>
>>
>>Peter