Nello
Firstly Tables are braindread - In fact in ADO a Table type command simply
inserts 'select * from' in front of the table name.
They have no place in an SQL based CS solution - they were an archaism
perpetuated for those diehard
ISAM programmers,
Use exclusively TQuery type components bacause
1/ It is consistent.
2/ It allows future server side restrictions.
3/ Querys abstract out the 'index' component so restructuring your db
doesn't break the app
Grids are not the criminal Nic says they are - but again keep the number of
records small
When I hear numbers like 20,000 record results I ask myself "What are these
guys doing?" and
"I often have application users who can absorb thousands of records in a
single glance :-)"
Writing table editors? - in 'real world' situations a grid can de restricted
to a few hundred records at most and
there is not problem esp with a client side dataset like ADO or Midas. Other
things to look at are
a/ ADO client engine allows editable joined data sets (aviods time/bandwidth
consuming local lookups)
(I assume the same could be coded in Midas)
b/ Both IB6 and MS SQL 2000 allow editable views (another way to avoid
time/bandwidth consuming local lookups)
(as an aside statistically small editable result set should reduce the
chance of conflict - another good reason)
The trick is for local lookups (if you wish to use them). Use a client side
cached dataset..Therefore they are only
feasible for small datasets. for large datasets - use a or b above
Avoid the Standard TQuery Master Detail support - It rigorously enforces
dataset validity which result in a zillion or so queries
being fired at your server - I have a TRelationship component which has a
propagation delay (source of which
anyone is welcome to - email me) So you can't 'tune' your applcation
Midas and the ADO Client engine make data-aware editing quite feasable and
efficient on C/S systems and
I assume some form of this funct will be in D6/Kylix
HTH
Neven
----- Original Message -----
From: Nello Sestini <[EMAIL PROTECTED]>
To: Multiple recipients of list delphi <[EMAIL PROTECTED]>
Sent: Friday, November 03, 2000 10:16 PM
Subject: Re: [DUG]: [Q] Lightweight DBMS....
> sayeth Nic ...
>
> > first rule of C/S: dont use tables.
> > second rule: dont use grids. They are an exceptionally bad UI
> > component with
> > anything but paradox-type things
>
> agreed - this is what i meant earlier when i said
>
> > I've avoided "aware" controls like grids for
> > exactly the reason Nic mentioned about the
> > "locate/findkey/next/prev etc" mentality.
>
> So what's all this about being able to get them
> to work if you "restrict your dataset" or
> "throw in MIDAS" ??
>
> That got my attention because I've assumed the
> "no grids" rule you just mentioned.
>
> -ns
>
>
>
>
> --------------------------------------------------------------------------
-
> New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
> To UnSub, send email to: [EMAIL PROTECTED]
> with body of "unsubscribe delphi"
>
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
