At 08:26 am 31/08/00 +1200, Jeremy Coulter said:
>>>>
Hi all....just a follow-up to my original ADO question of a couple of days
ago.....what are the advantages is not using DB Bound controls as apposed
to non bound controls in an application.
I can think of a couple of fores and against for both senarios.....to me,
not binding seems to be a lot of work....but does this increase flexability ??
Is it a speed issue ?
Interested to know why people went non bound instead of using bound
controls etc.
Thanks,
Jeremy Coulter
<<<<
Jeremy, all, I've been off this list for a couple of years so nice to see
some of the same names again. Interesting to see Max's view as I have been
following his progress with interest as it seems the direct opposit of the
way I have gone and I'm interested in how we compare (gidday Max if you're
listening - Profax being a very old friendly rival in the same market at
the time).
Interesting timing as I've just spent the morning talking through this very
question of bound and unbound with a person just learning Delphi. Basically
I have 3 rules:
1. Don't fight the system
2. Don't (try not to) use 3rd party components
3. Grids are not data input devices
#1 is the most important as this keeps your end product as close to Windows
standard as possible (yea I realise that's not necessarily a good thing to
some people). Although I have a great deal of fun playing with creating my
own components, I don't use them or 3rd party components in my own code.
This causes problems but the benefits outweight them.
I will use bound controls only in smaller local applications that use
tables, and unbound controls (apart from DBGrid) in larger client/server
applications. The latter will require more control on the update process
where I generally use an internally created query rather than attach an
UpdateSQL to a dropped TQuery.
On a smaller system with small tables there are several advantages
including: speed of development, OnValidate(), a user interface more
related to small system wth a single user (forwards, back etc.).
Disadvantages include: limited components, more checking when changing
(especially if using AutoEdit := true and arrows), and components you may
have used elsewhere (e.g. DateTimePicker) cannot be used.
However, as I stated, on larger client/server projects wher the back end
database may be changed at a later date, I usually wish to be as standard
as possible in relating to the database with full control via pure SQL. In
this instance I will use unbound controls and, if I even use them, will
directly program in forwards/backwards etc.
All comes down to the size of the database and the typical installation of
the application.
Steve
Steve Peacocke
(025) 951-251
Dilbert: "Do not meddle in the affairs of dragons for thou art crunchy and
wouldst taste good with sauce"
---------------------------------------------------------------------------
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"
