Hi

We have a lot o DataModules in our project and we want to share between
diferents Units in our same project.

Our problem is that when we are sharing a DataSet it could be modified
at the same time by diferents methods and this is  really a problem.

We try to convert each DataModule  into a true TClass but it is too
complex to create if a DataModule(1) use another DataModule(2) which
also is created on the fly and it get worst when DataModule(2) also uses
DataModule(1).

Are we going in the wrong way?
What tip could you give me?

Thanks

Alvaro

"Are we going in the wrong way?"
Why do you share DataModules?  I share a few DataModules for real short
SELECT's or INSERT's, etc; but they have no lifespan.  I try to stay away
from anything global (shared).

eGreg

Alvaro Boldo <abo...@sorteotec.mty.itesm.mx> wrote in article
<39C97610.97EE8...@sorteotec.mty.itesm.mx>...

You can give the inheritence a try.

I did it, but only for a kind of lookup datasets, not for editable datasets.

J.W. de Bokx

You could create instances of the data module dynamically as needed.  You'd
have to manually adjust references to the data module from other forms, but
this will allow you to do what you want.

Dan

news:39C97610.97EE8AC4@sorteotec.mty.itesm.mx...

Well I don't know exactly what your doing so forgive me if I'm a little bit
off on any of this.  It's normally bad design to have any 2 forms / grids
pointing to the same dataset.  This is fine for small projects but when you
start working with 400 forms then you don't want to have to track down why
one dataset is behaving strangly.

Now if you want dataset reuse there are a couple of options.  One you can
use Midas and go three tier, or second you can use the Midas components in
one app and just have more than one clientdataset pointing to the same
provider, or three you can use the clientdataset.clonedataset method.

Something that actually seems to be backwards, but works rather well, is
putting datasets on the forms themselves.  Yes some schools of thought would
say you want interface and biz rules to be separate.  I believe in reality a
lot of biz logic has to go into the interface to begin with.  When you
define a drop down, or a grid you are putting constraints on the data and
interface in some way.  If you abstract all of the dataaccess then you also
have to abstract all of the interface (This means no more using dataaware
controls).  and I just dont think the cost / benifit is there.  But I've
found making each form a "complete package" works very well.  This also
allows you to create more than one instance of a form, and each form manages
its own data.  I still use data modules, but only for more global stuff and
for some biz logic.  I don't ever tie a dataware control to a dataset on a
datamodule.

Just some thoughts.

Blaine Whittle
Apropos Retail

news:39C97610.97EE8AC4@sorteotec.mty.itesm.mx...

Ok, I think I got it if we only talk about DataSet but, what about TSession,
TQuery, TStoreProcedures ? I have a data module with just one TQuery and I reuse
it in a lot of methods whitin the DataModule.

Please, check my code and tell me if I'm going wrong.
Note that UMedioVentaDM uses UPadreDM and UInicioSesionDM

Example

unit UAtomoDM1;

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
  Oracle;

type
  TPadreDM = class(TDataModule)
  qryRead: TOracleQuery;
  private
  { Private declarations }
  public
  { Public declarations }
  Procedure LeeDB(qryLocal:TOracleQuery);

  end;

implementation

uses UInicioSesionDM;

{$R *.DFM}
Procedure TPadreDM.LeeDB(qryLocal:TOracleQuery);
begin
 with qryLocal do
 begin
  Close;
  Execute;
 end;
end; //TPadreDM.Lee

//////////////////////////////////////////////////////////////////////////

unit UMedioVentaDM  ;

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
  Oracle;

type
  TMedioVentaDM = class(TDataModule)
  OracleQuery1: TOracleQuery;
  private
  { Private declarations }
  public
  { Public declarations }
  Function getNombreMedioVenta(qryMiObjeto: TOracleQuery; iIDMedioVenta :
string):string;
  end;

implementation

uses UPadreDM, UInicioSesionDM;

{$R *.DFM}
Function TMedioVentaDM.getNombreMedioVenta(qryMiObjeto: TOracleQuery;
iIDMedioVenta : string):string;
begin
  OracleQuery1.Clear;
  OracleQuery1.SQL.Add('Select pe.primernombre,pe.segundonombre, ');
  OracleQuery1.SQL.Add('       pe.apellidopaterno,pe.apellidomaterno ');
  OracleQuery1.SQL.Add('From persona pe,medioventa mv ');
  OracleQuery1.SQL.Add('where pe.idpersona = mv.idpersona ');
  OracleQuery1.SQL.Add('  and mv.idmedioventa = '+ iIDMedioVenta);

  UPadreDM.PadreDM.LeeDB(OracleQuery1);
  if not OracleQuery1.Eof then
  begin
   Result:= OracleQuery1.FieldAsString('primernombre') + ' ' +
      OracleQuery1.FieldAsString('segundonombre') + ' ' +
      OracleQuery1.FieldAsString('apellidopaterno') + ' ' +
      OracleQuery1.FieldAsString('apellidomaterno');
  end;
end;

So... what code you think I use in a DataModule? where do I must this code, in a
DataModule or in a Unit or what? I need to reuse this kind of querys.

Function TMedioVentaDM.getNombreMedioVenta(qryMiObjeto: TOracleQuery;
iIDMedioVenta : string):string;
begin
  OracleQuery1.Clear;
  OracleQuery1.SQL.Add('Select pe.primernombre,pe.segundonombre, ');
  OracleQuery1.SQL.Add('       pe.apellidopaterno,pe.apellidomaterno ');
  OracleQuery1.SQL.Add('From persona pe,medioventa mv ');
  OracleQuery1.SQL.Add('where pe.idpersona = mv.idpersona ');
  OracleQuery1.SQL.Add('  and mv.idmedioventa = '+ iIDMedioVenta);

  UPadreDM.PadreDM.LeeDB(OracleQuery1);
  if not OracleQuery1.Eof then
  begin
   Result:= OracleQuery1.FieldAsString('primernombre') + ' ' +
      OracleQuery1.FieldAsString('segundonombre') + ' ' +
      OracleQuery1.FieldAsString('apellidopaterno') + ' ' +
      OracleQuery1.FieldAsString('apellidomaterno');
  end;
end;

Hi Blaine!

On Thu, 21 Sep 2000 11:27:29 -0700, "Blaine Whittle"

I would disagree on this... Having more then one form on the same
dataset is a kind of a must in some situations. Consider one form as a
query form, where you can modify what selection data scope you want to
see, there is a grid and you browse through data. Then, when you want
to see one record in detail, you double click in the grid and another
form shows up the same record in detail. There you can modify the
record, enter new records, etc. So there you have two forms operating
on the same dataset. In this situation I use naming convention like:

<prefix>Data      - Data module for all the database access and logic
<prefix>QMR       - Query multi record form
<prefix>SR                - Single record form

So, having same prefix they all line up together in project manager
and I know they relate to the same data module.
Another use for more forms accessing to the same dataset is for the
lookup purpose... Lookup data is used on many places but why should I
define many lookup datasets on the same table, I simply use one common
data module with all the stuff that is needed generaly.

When I started working with delphi, that was the way I done all my
forms. Now, after some years of experience I use both... Dataset's
that are ment for data entry I separate in datamodule and those
dataset's that are ment only for viewing on some view only forms I put
on the forms itself.

Why I do like that? Because of my QMR i SR forms! Now I can link only
SR form to my datamodule, or I can link both QMR and SR. I can make
more then one instance of datamodule and more then one instance of SR
form and show few records in the same time on the screen allowing data
entry in all of them without duplicating dataset's events code. It's
much cleaner that way for me.

Also, in my apps forms that are not shown are destroyed automaticaly.
Datamodules have reference counts and when no one needs them, they are
also destroyed too. Every form in create section references
datamodules it needs, or gets some through parameters depending on the
logic. In the destroy section, datamodels are de-referenced. So, I use
the least memory/resource requirements I can. Of course there is an
overhead of constant forms/datamodules creation and destruction but
this is fast enough for me and the user...

tomi.