.dbc vs. free tables 
Author Message
 .dbc vs. free tables

i'm an inexperienced vfp programmer.  in a nutshell, can you forewarn me
on my stubborness to stick to free table style as engrained in me by
foxpro 2.6, even though i'm now using vfp6.

at this juncture of my programming experience, i cannot still see the
larger context of the big picture.  i shudder to think that if i
continue to use free tables, i may regret it later.

 i may have a culture shock with the '.dbc'.  but a good advise will
always matter to me.  guiding hands, for me, are ethereal gifts. and
many thanks for it.



Fri, 05 Apr 2002 03:00:00 GMT  
 .dbc vs. free tables
Using DBC will expose you to a big brother DBMS features such as triggers,
defaults, rules, referential integrity, stored procedure, table buffering,
etc. This is a really cool stuff 'ya know, and closing yourself to DBC will
surely make you going to regret it later. I'm not sure where you plan your
programming carrer to, but if one day you anticipate your self to do
programming in higher calibre DBMS (ms-sql, IBM DB2, Sybase, Informix),
using DBC is a good potty training.

In addition to that, using DBC will increase you productivity on you current
and upcomming projects.

I strongly suggest to look into it. There are so many potentials of DBC (vs
free table), and could be worth of 1 or 2 days lecture/workshop to explore.

best regards.

Quote:

> i'm an inexperienced vfp programmer.  in a nutshell, can you forewarn me
> on my stubborness to stick to free table style as engrained in me by
> foxpro 2.6, even though i'm now using vfp6.

> at this juncture of my programming experience, i cannot still see the
> larger context of the big picture.  i shudder to think that if i
> continue to use free tables, i may regret it later.

>  i may have a culture shock with the '.dbc'.  but a good advise will
> always matter to me.  guiding hands, for me, are ethereal gifts. and
> many thanks for it.



Fri, 05 Apr 2002 03:00:00 GMT  
 .dbc vs. free tables
Mario,

Will you need to continue accessing the same 2.6 tables from FP2.6 as well
as your new VFP app?  If so, you must stay with free tables, since attaching
them to a DBC makes them incompatible with 2.6.

You can, however, build local views in the DBC that access the 2.6 tables
and leave them available to your 2.6 apps.

If you don't need 2.6 compatibility, then go for attaching the tables to DBC
(referred to as "contained tables"), and reap the many benefits.

David Stevenson
Dave in Atlanta

Quote:

>i'm an inexperienced vfp programmer.  in a nutshell, can you forewarn me
>on my stubborness to stick to free table style as engrained in me by
>foxpro 2.6, even though i'm now using vfp6.

>at this juncture of my programming experience, i cannot still see the
>larger context of the big picture.  i shudder to think that if i
>continue to use free tables, i may regret it later.

> i may have a culture shock with the '.dbc'.  but a good advise will
>always matter to me.  guiding hands, for me, are ethereal gifts. and
>many thanks for it.



Fri, 05 Apr 2002 03:00:00 GMT  
 .dbc vs. free tables
In addition to the other posts: Get a copy of GenDBCX.



Quote:
> i'm an inexperienced vfp programmer.  in a nutshell, can you forewarn me
> on my stubborness to stick to free table style as engrained in me by
> foxpro 2.6, even though i'm now using vfp6.

> at this juncture of my programming experience, i cannot still see the
> larger context of the big picture.  i shudder to think that if i
> continue to use free tables, i may regret it later.

>  i may have a culture shock with the '.dbc'.  but a good advise will
> always matter to me.  guiding hands, for me, are ethereal gifts. and
> many thanks for it.



Fri, 05 Apr 2002 03:00:00 GMT  
 .dbc vs. free tables
I started using VFP when version 3 first came out, and today I still use
some free tables in my apps. The biggest advantage to using the DBC for me
is long field names and views. Referential Integrity via the DBC features is
not very robust, I use a framework to apply RI to DBC and non-DBC tables.
Likewise with triggers and default values, I use a framework to apply this
to non-DBC tables as well. The DBC is OK, but there are better and faster
ways to do some of things you can do with the DBC. It is also a PITA to
reindex the tables if you are writing your own reindex routine. I've trashed
more than one DBC by accident and lost my long field names and views, I've
learned to be carefull about what I do.

If you are new to VFP, you might take a look at some of the frameworks
available. A good one will allow you to produce industry strength apps
without becoming a VFP expert, you can be productive while you learn.
www.promatrix.com is a good one, it is a high level framework and very well
suited to business solutions. There are several other good ones available as
well.



Quote:
> i'm an inexperienced vfp programmer.  in a nutshell, can you forewarn me
> on my stubborness to stick to free table style as engrained in me by
> foxpro 2.6, even though i'm now using vfp6.

> at this juncture of my programming experience, i cannot still see the
> larger context of the big picture.  i shudder to think that if i
> continue to use free tables, i may regret it later.

>  i may have a culture shock with the '.dbc'.  but a good advise will
> always matter to me.  guiding hands, for me, are ethereal gifts. and
> many thanks for it.



Fri, 05 Apr 2002 03:00:00 GMT  
 .dbc vs. free tables

Quote:
> The DBC is OK, but there are better and faster
> ways to do some of things you can do with the DBC.

Yeah right! like what?

Meanwhile, try to create something that can do this:

     Table: OrderDetail:
     fields: ItemCode, QtySold.

     Table: Inventory
     fields: ItemCode and QtyAvailable.

ItemCode and QtySold related to table inventory in such way that  if QtySold
increase, QtyAvailable (for the same Item) automatically decrease, and vice
versa. And when you delete record, the subsequence Qty value will be returned to
Inventory.

Here's the catch, this action should be achieved via many "raw" ways include:
- Direct field edit from simple browse (without browse snippets just plain
BROWSE NORMAL via command window)
- Programmatically change from simple code like Replace QtySold with QtySold+5

Can you do this without triggers?
What about table buffering? what about Begin Transaction ...End Transaction?

Quote:

> If you are new to VFP, you might take a look at some of the frameworks
> available. A good one will allow you to produce industry strength apps
> without becoming a VFP expert, you can be productive while you learn.
> www.promatrix.com is a good one, it is a high level framework and very well
> suited to business solutions. There are several other good ones available as
> well.

Agreed. I own and use Promatrix, VisualFoxExpress (which I like more, n-tier,
dcom stuff), CodeBook since their FPW days. But the issue here is the DBC. There
are some features in VFP that can only be accessible if you using DBC. Off
course you can mimics and achieve the same result via bigger complicated coding.

DBC has it own problems (Mr. Stevenson has good point in laying out the cons of
DBC) but the benefits surpass it's problems, and there are always workarounds
for it.

I think we should not discourage Mr. Buzon to learn the technology that has been
adapted from prominent RDBMS. Technology that had become dream for some desktop
database (xbase) for many years.

Just my two cents. No offend intended.

farid



Sun, 07 Apr 2002 03:00:00 GMT  
 .dbc vs. free tables
If you want to get helpful information from this technical
newsgroup, the "Yeah right! like what?" response is
(IMHO) hardly like to endear you to those who have
attempted to help you so far. Or anyone else.

Using free tables is fine.
You can use buffering.

If you want to use RI, triggers, default values, transactions,
views - then you'll need a dbc.
Your choice.
Otherwise write code to handle this with free tables.

Yes, you can do it without triggers.
What about buffering and transactions?
Read online help!

Roger


Quote:
> > The DBC is OK, but there are better and faster
> > ways to do some of things you can do with the DBC.

> Yeah right! like what?

> Meanwhile, try to create something that can do this:

>      Table: OrderDetail:
>      fields: ItemCode, QtySold.

>      Table: Inventory
>      fields: ItemCode and QtyAvailable.

> ItemCode and QtySold related to table inventory in such way that  if QtySold
> increase, QtyAvailable (for the same Item) automatically decrease, and vice
> versa. And when you delete record, the subsequence Qty value will be returned
to
> Inventory.

> Here's the catch, this action should be achieved via many "raw" ways include:
> - Direct field edit from simple browse (without browse snippets just plain
> BROWSE NORMAL via command window)
> - Programmatically change from simple code like Replace QtySold with QtySold+5

> Can you do this without triggers?
> What about table buffering? what about Begin Transaction ...End Transaction?

> > If you are new to VFP, you might take a look at some of the frameworks
> > available. A good one will allow you to produce industry strength apps
> > without becoming a VFP expert, you can be productive while you learn.
> > www.promatrix.com is a good one, it is a high level framework and very well
> > suited to business solutions. There are several other good ones available as
> > well.

> Agreed. I own and use Promatrix, VisualFoxExpress (which I like more, n-tier,
> dcom stuff), CodeBook since their FPW days. But the issue here is the DBC.
There
> are some features in VFP that can only be accessible if you using DBC. Off
> course you can mimics and achieve the same result via bigger complicated
coding.

> DBC has it own problems (Mr. Stevenson has good point in laying out the cons
of
> DBC) but the benefits surpass it's problems, and there are always workarounds
> for it.

> I think we should not discourage Mr. Buzon to learn the technology that has
been
> adapted from prominent RDBMS. Technology that had become dream for some
desktop
> database (xbase) for many years.

> Just my two cents. No offend intended.

> farid



Sun, 07 Apr 2002 03:00:00 GMT  
 .dbc vs. free tables
Ah... it's Roger Ansell again. The man who has gift from God to see the crux of the
problem. You know, it's quite an honor to be critized by you. Your knowledge and
excellent writing skill enable me to see how imperfect I can be.

Slap my own wrist this time, my apology.

farid

Quote:

> If you want to get helpful information from this technical
> newsgroup, the "Yeah right! like what?" response is
> (IMHO) hardly like to endear you to those who have
> attempted to help you so far. Or anyone else.

> Using free tables is fine.
> You can use buffering.

> If you want to use RI, triggers, default values, transactions,
> views - then you'll need a dbc.
> Your choice.
> Otherwise write code to handle this with free tables.

> Yes, you can do it without triggers.
> What about buffering and transactions?
> Read online help!



Mon, 08 Apr 2002 03:00:00 GMT  
 .dbc vs. free tables
Flattery will get you nowhere! <g>

But whoops! Even the "perfect me", all replete with God's gifts,
can sometimes screw-up (that's a Godly term, you understand).
I erroneously  thought you were the original poster, answering
a helpful response. And therefore I completely mis-construed
your message.

My fault, no question.

I apologise and retract what I said.

Roger

PS
You do a good line in sarcasm - keep it up!


Quote:
> Ah... it's Roger Ansell again. The man who has gift from God to see the crux
of the
> problem. You know, it's quite an honor to be critized by you. Your knowledge
and
> excellent writing skill enable me to see how imperfect I can be.

> Slap my own wrist this time, my apology.

> farid


> > If you want to get helpful information from this technical
> > newsgroup, the "Yeah right! like what?" response is
> > (IMHO) hardly like to endear you to those who have
> > attempted to help you so far. Or anyone else.

> > Using free tables is fine.
> > You can use buffering.

> > If you want to use RI, triggers, default values, transactions,
> > views - then you'll need a dbc.
> > Your choice.
> > Otherwise write code to handle this with free tables.

> > Yes, you can do it without triggers.
> > What about buffering and transactions?
> > Read online help!



Tue, 09 Apr 2002 03:00:00 GMT  
 .dbc vs. free tables
AL

I've replied and apologised to Farid.
I was completely out of line.

And as I speak, I'm committing ritual hari-kiri in a
10-foot-deep pit of organic compost.

BTW
I bumped into Dan Madero in my local shopping mall
this morning. He was very dark about the things that had been
said about him and told me he's hired the services of the infamous
law firm Sue Grabbit & Runne to make life utterly miserable
for Storage Lady (and others) for the next decade or so.
After a couple of capuccinos, I managed to persuade him
to drop the legal action. Trouble is, he's now talking about
Direct Action using his connections with unsavoury gangster
elements in LA. I told him that this wasn't the FoxPro way of doing
things, but he just won't listen.

Any suggestions?

Roger


Quote:
> Go for it you two and any one else who wants to join in.  I was getting
> bored now that the Dan Madero affair has waned  <g>

> Just to keep the pot bubbling
> By the way Roger, Farid wasn't asking for help, so wasn't likely to offend.
> If you had read the complete post you would see that he was responding to an
> earlier opinion

> Regards
> AL



> >Ah... it's Roger Ansell again. The man who has gift from God to see the
> crux of the
> >problem. You know, it's quite an honor to be critized by you. Your
> knowledge and
> >excellent writing skill enable me to see how imperfect I can be.

> >Slap my own wrist this time, my apology.

> >farid


> >> If you want to get helpful information from this technical
> >> newsgroup, the "Yeah right! like what?" response is
> >> (IMHO) hardly like to endear you to those who have
> >> attempted to help you so far. Or anyone else.

> >> Using free tables is fine.
> >> You can use buffering.

> >> If you want to use RI, triggers, default values, transactions,
> >> views - then you'll need a dbc.
> >> Your choice.
> >> Otherwise write code to handle this with free tables.

> >> Yes, you can do it without triggers.
> >> What about buffering and transactions?
> >> Read online help!



Tue, 09 Apr 2002 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. DBC vs. Free Tables in ODBC

2. Free Tables vs DBC

3. Free tables vs dbc

4. dbc VS Free tables

5. dbc vs free table

6. Database table vs Free table ?

7. Set relation problems between DBC and free tables

8. Performance of Free tables compared to within a DBC

9. How to import hundreds of free table to one DBC

10. Free Tables to DBC - Is behaviour different?

11. Databases vs. Free Tables

12. DBF vs Free Tables

 

 
Powered by phpBB® Forum Software