OK, In the past I have put all data sources, tables, queries, etc in one
or more data modules.  However, in some cases (where a datasource and
table are only accessed by one form) I would like to place the datasource
and table on the form which uses them.  Since I generally prefer to
instantiate forms as they are used, and to only have tables active that
are actually in use, having them on the form makes this easier (and easier
for another programmer to read).  Otherwise, I have to add code to
activate and deactivate the tables in the code which calls the form (much
more elegant to do this in the OnCreate or OnDestroy of the form).

The only issues I can think of is that each form must then USE the DBxxxx
units, instead of just the datamodule unit.  Also, I would still need to
define a central location for the TSession - either in a datamodule or the
main form.

Is there any reason why I shouldn't keep the Data Access controls on the
form that they are used?  Am I costing my application any performance,
functionality, or stability?

Any reply to my question is greatly appreciated.

Keith Rome
high...@linknet.net

My opinion is that it is almost always best to put the data access
controls in a data module or on a form that is used like a data
module.

Here's a few reasons off the top of my head...

1) If you ever need to have more than 1 form based on that data model,
you can do it without making changes.

2) If you decide later to split the form into 2 or more forms that
work together, you don't disturb the data model.

3) If you decide later to combine several forms into one, you don't
disturb the data model.

4) It provides a place to centrally locate business rules and keeps
them out of the User Interface.  This is especially important for
client-server because if you need to go to a 3-tier architecture
later, you can do it more easily.

Regards,

David Orme
:======================================================:
: David J. Orme             Coconut Palm Software, Inc.
:  "Delphi Intranet Solutions for your business needs"
:            http://www.computervision.com
:======================================================:

chris houghten <choug...@mcgh.org> wrote in article

The only problem I have encountered is reporting back to interface when a
posting error has occured.  In proir products once an error or warning
occurs it is nice to set the focus back to the field which caused the
problem.  However, the datamodule has
no knowledge about the form, or the fields on that form.  I have work
around, which basically loops through the components on the form, looks for
a TDBEdit (or whatever) with a fieldname property of the offending field
name.

Mike J.

thanks

Koh Yang Uei

 "Declaration
  function FocusControl;

  Description
  Sets a form's focus to the first data-aware component associated with a
  TField. Use this method when doing record-oriented validation (for example,
  in the BeforePost event) since a field may be validated whether its
  associated data-aware components have focus."

One other way of doing this is to use the same event code on a single
unit. For all tables that use that table, after opening the table set the
event properties to the form or unit that contains the code e.g
Table1.BeforePost : = UnitX.Routine. The UnitX,Routine does not have to be
attached to a table, it only has to be of the same procedural type as the
BeforePost event.
This allows you to centralize certain events, similar to SQL triggers
using one set of codes, and other events handled differently according to
form.
For instance events triggered by a user editing the table manually can be
handled differently from computerised large scale data updates, where
certain checks are irrelevant, time wasting and some exceptions logged to
a file, rather than being aborted to wait for some response from the user.
When an error occurs, trap the owner of the TTable currently using the
code, that will be the form with the error.

Using Delphi 1, I find it easier to use this method, because having the
datasources on all forms in sync with the form current using the code is
can be undesirable in some cases.

John Petersen <jo...@post1.tele.dk> wrote in article
<31F017F1.1...@post1.tele.dk>...

Koh :
Here is some sample code to scroll through the components on a form:

while ( I < ComponentCount ) AND ( bFound <> TRUE ) do begin
        if ( Components[I] is TDBEdit ) AND (
TDBEdit(Components[I]).DataField =                                 sFldName
) then begin
            bFound := TRUE;
            TDBEdit(Components[I]).SetFocus;
            end; // if ... then begin
        Inc(I);
        end; // while ... do begin

Mike

Koh Yang Uei <ab...@singnet.com.sg> wrote in article

The code to loop through controls on the form is :

    while ( I < ComponentCount ) AND ( bFound <> TRUE ) do begin
        if ( Components[I] is TDBEdit ) AND (
TDBEdit(Components[I]).DataField =                                        
                      sFldName ) then begin
            bFound := TRUE;
            TDBEdit(Components[I]).SetFocus;
            end; // if ... then begin
        Inc(I);
        end; // while ... do begin