Board index » cppbuilder » Database Tables & Queries

Database Tables & Queries


2004-11-09 02:08:20 PM
cppbuilder85
BCB makes interfacing to a database so simple, but I am becoming concerned
about the many TTable & TQuery components in my application, all of which
are active all of the time.
What is good practice wrt TTable and TQuery components? Should I attempt to
close tables that are not in current use? I imagine this might be fairly
messy because of lookup fields in one table referring to other tables etc.
 
 

Re:Database Tables & Queries

Marco wrote:
Quote
BCB makes interfacing to a database so simple, but I am becoming concerned
about the many TTable & TQuery components in my application, all of which
are active all of the time.
What do you call 'many'?
Quote
What is good practice wrt TTable and TQuery components? Should I attempt to
close tables that are not in current use? I imagine this might be fairly
messy because of lookup fields in one table referring to other tables etc.
If the tables are related you should let them active too I think.
But I never used those components, besides for looking at the
examples demos, so I cann't tell you.
Hans.
 

Re:Database Tables & Queries

I must have about 200 table & query components logically grouped into about
30 data modules.
"hans galema" < XXXX@XXXXX.COM >wrote in message
Quote
Marco wrote:
>BCB makes interfacing to a database so simple, but I am becoming
concerned
>about the many TTable & TQuery components in my application, all of
which
>are active all of the time.

What do you call 'many'?

>What is good practice wrt TTable and TQuery components? Should I
attempt to
>close tables that are not in current use? I imagine this might be
fairly
>messy because of lookup fields in one table referring to other tables
etc.

If the tables are related you should let them active too I think.
But I never used those components, besides for looking at the
examples demos, so I cann't tell you.

Hans.
 

{smallsort}

Re:Database Tables & Queries

"Marco" < XXXX@XXXXX.COM >wrote:
Quote

I must have about 200 table & query components logically
grouped into about 30 data modules.
Just so that I know that you know ... you don't need a TTable
(and TQuery) for every table in the db. I agree that it's
easier to setup in the IDE but it could be to your benifit to
dynamically allocate and/or link the components together.
Quote
What is good practice wrt TTable and TQuery components?
Should I attempt to close tables that are not in current
use? I imagine this might be fairly messy because of lookup
fields in one table referring to other tables
I always use a TDataSet (mostly dynamically allocated). The
main reasons are because working with the entire table can
significantly reduce performance and if you're going to work
with blobs it's a must.
Like Hans, I don't use TDBxx components but I will tell you
that I think that manipulating the table directly is not the
best choice.
As an example of not using TDB components, assume you need to
view invoices by customer. Using a TDataSet, one select is
used to load a TComboBox and another select in the OnSelect
event loads a TStringGrid. After every select, the TDataSet is
closed so there is never an open table.
TDB components does make it easy to enter/edit data but I find
the components flexibility limiting in terms of validating data
and manipulating the GUI.
First and foremost, if the user enters invalid data, I don't
want them getting some cryptic db error message because all
they're going to do is complain and call me (us) and we have
to spend time determining exactly what happened and then
explain to the user that 'it's a numeric field. You can't use
letters in that field (stupid)!!'
It may make for more coding but in terms of inspiring
confidence in your program and time saved in user support,
it's well worth the effort and it allows you to do more with
the GUI.
Segregating the components into seperate DataMods is a good
start but if you look closely at them, I'm betting that you'll
see so many similarities that with the exception of the table
names, you might have 5 or 6 different ones. If so, you could
remove them from the auto create list and dynamically allocate
them as needed.
The truth is that I've only ever seen a relational database
that needed that many tables once and it was for a fortune 500
company.
~ JD
 

Re:Database Tables & Queries

Marco wrote:
Quote
Thanks, this is exactly the type of advice I am looking for.
That's great news but can I ask you to trim your quoting, please?
Thanks.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Database Tables & Queries

Thanks, this is exactly the type of advice I am looking for. The help &
books seem to ignore this practical advice. Thanks a lot JD - it'll take me
a while to digest this and try out some things you mention.
I guess you are are telling me to forget about the visual components that
connect directly to a data source. I was wondering about this because once
one uses them it becomes more difficult to separate the user interface from
the database.
cheers,
Marco
"JD" < XXXX@XXXXX.COM >wrote in message
Quote

"Marco" < XXXX@XXXXX.COM >wrote:
>
>I must have about 200 table & query components logically
>grouped into about 30 data modules.

Just so that I know that you know ... you don't need a TTable
(and TQuery) for every table in the db. I agree that it's
easier to setup in the IDE but it could be to your benifit to
dynamically allocate and/or link the components together.

>What is good practice wrt TTable and TQuery components?
>Should I attempt to close tables that are not in current
>use? I imagine this might be fairly messy because of lookup
>fields in one table referring to other tables

I always use a TDataSet (mostly dynamically allocated). The
main reasons are because working with the entire table can
significantly reduce performance and if you're going to work
with blobs it's a must.

Like Hans, I don't use TDBxx components but I will tell you
that I think that manipulating the table directly is not the
best choice.

As an example of not using TDB components, assume you need to
view invoices by customer. Using a TDataSet, one select is
used to load a TComboBox and another select in the OnSelect
event loads a TStringGrid. After every select, the TDataSet is
closed so there is never an open table.

TDB components does make it easy to enter/edit data but I find
the components flexibility limiting in terms of validating data
and manipulating the GUI.

First and foremost, if the user enters invalid data, I don't
want them getting some cryptic db error message because all
they're going to do is complain and call me (us) and we have
to spend time determining exactly what happened and then
explain to the user that 'it's a numeric field. You can't use
letters in that field (stupid)!!'

It may make for more coding but in terms of inspiring
confidence in your program and time saved in user support,
it's well worth the effort and it allows you to do more with
the GUI.

Segregating the components into seperate DataMods is a good
start but if you look closely at them, I'm betting that you'll
see so many similarities that with the exception of the table
names, you might have 5 or 6 different ones. If so, you could
remove them from the auto create list and dynamically allocate
them as needed.

The truth is that I've only ever seen a relational database
that needed that many tables once and it was for a fortune 500
company.

~ JD