Unit? Datamodule? Whats the right way?

[Mike.Cornflake]

@CodeLizard

And there you have it :-)   Half of us are recommending DataModules, and half are recommending a more code based solution.  We're all making our calls based on our experience and training.  We got our experience by making mistakes, both in planning and in implementation.  I think you're trying to get the perfect solution before you even start coding.  Aint going to happen, no matter what language.

:-) I've changed my advice.   I used to recommend a code based solution.  Now I'm recommending *anything*.   It's time for you to start :-)  Sure you'll end up having to refactor, but that will add to your Pascal experience, no bad thing.   You get stuck on specific code, then post away :-)

[Codelizard]

@Mike

Yeah, all kinds of ideas flying in across the board.  I myself come from a background of the code solution, so this is the way I am inclined to do it, at least to start.  My issue, as I stated earlier, is in your example I don't see how to make the connection global, or act like its global.  Thats the piece i dont understand.

If I create code at app startup that loads a unit, then everywhere else i use that unit, does it share the same variables from the interface section?  Is that the key?

Thats what I am grasping at in the code solution...  Once I get that, I can start coding without having to learn simpletons and datamodules right now.

[Mike.Cornflake]

If I create code at app startup that loads a unit, then everywhere else i use that unit, does it share the same variables from the interface section?

Yes :-)  But you'd have confirmed that by writing perhaps 10 lines of code and testing.  All the information you need has been presented here.  Time to start experimenting :-)

[taazz]

there is no such thing as "not recommended to use" component technique or pattern only "not recommented to be used like that or for that purpose" datamodules where introduced for a purpose to be able to write db and domain/bussines specific code in a single place and not have it all over the place. For this they are doing their job well. Look at them as the frames of the data applications. a single datamodule can be eg customers can have properties and methods eg dmCustomers.beginTransaction; dmCustomers.Comit; dmCustomers.Update; etc. and usually can be set to be a black box to the outside world too.

So use them it is for your own good that they are there. If you do not plan to use dbaware control in the visual/form designer then I guess it has no big difference between datamodule and hand coded units but if you do plan to use dbaware controls then datamodules there is no second choice to be even ranked.

@Mike

Yeah, all kinds of ideas flying in across the board.  I myself come from a background of the code solution, so this is the way I am inclined to do it, at least to start.  My issue, as I stated earlier, is in your example I don't see how to make the connection global, or act like its global.  Thats the piece i dont understand.


If I create code at app startup that loads a unit, then everywhere else i use that unit, does it share the same variables from the interface section?  Is that the key?

correct once a variable is declared in a units interface section all other units that access it see and change the same data.

Thats what I am grasping at in the code solution...  Once I get that, I can start coding without having to learn simpletons and datamodules right now.

well there you have it then.

[Codelizard]

Thanks guys for everything...

You're right, if I started playing, I probably would have figured some of this out by now.   I've been spending the last few days finishing up a few other projects and getting them off my plate so I have time now to jump in.  I was just taking some of the time I have trying to get a better perspective so I can hit the ground running.

As far as the datamodules, I do not discount their value at all.  But for this particular project and the different methods I'm going to be approaching for the database i/o, I'm going to go with custom DB classes.  Besides, what better way to get a handle on the language

As I said, between what I've read and what you guys have offered up, I've learned alot.  Can't wait to use it!

Thanks

[Codelizard]

So, I thought I'd follow up and let you know that I've got this working in my testing.

On my main form, I've got a bunch of SQLDB controls (i couldnt make this work without having these controls present).  I then add a couple of properties to the form.  These properties represent the TSQLConnection and TSQLQuery objects.

I then have a unit called dbMain.  DBMain has procedures for connectDB, closeDB, etc.  It uses mainForm (the reference to my main form) in the implementation, and then actually opens the connection and assisgns it to the mainform property.

I have also created a class for one of my tables, which i create right after the DB is opened.  The class reference also belongs to the mainForm.

So now, i have the connection, the sqlquery, and my class all open and connected, and belonging to the mainform.  In my tests, I then just include mainform in the implementation and use anything I need to.  ALL of the data I/O happens inside the classes.  So if I need to add a new record for time, I just:

frmMain.dbTime.clear
frmMain.dbTime.DateIn := xxxxxx;
frmMain.dbTime.TimeIn := xxxxxx;
frmMain.dbTime.Status := xxxxxx;
frmMain.dbTime.add;

And the class handles all of the additional logic that I would normally have to do when creating such a record.  I'll admit, figuring out the proper way to get the transactions working was a little of a pain.  So much documentation, but so much of it is very focused.  Tells me everything about the Transaction object, but not the right sequence to use it when referencing the DB and the query, and when to commit.  When you're doing this code by hand and not through the controls, the documentation comes up a little short.  I had to hunt and peck, trying different things, until it worked.

So, I'm sure there may be some flaws in what I'm doing, but I'm sure I'll work them out in time.  I'm only a small step along the way getting things done, but very excited at the pieces I've already begin to create.

Thanks for the input and help from everyone who took the time out to read and comment.

[mangakissa]

On my main form, I've got a bunch of SQLDB

Do you also have other components on your mainform?

And the class handles all of the additional logic that I would normally have to do when creating such a record.

And that's logical?. You can also put all your connections and queries in this class, so all your handles are on the same class. 

I'll admit, figuring out the proper way to get the transactions working was a little of a pain.  So much documentation, but so much of it is very focused.  Tells me everything about the Transaction object, but not the right sequence to use it when referencing the DB and the query, and when to commit.  When you're doing this code by hand and not through the controls, the documentation comes up a little short.

You read to mutch. Just try the SQLdb tutorials practically.
It isn't so hard to do it programmatically.

Code: [Select]

procedure TSQLdbClass.InsertRecord(aConn : TSQLConnection; const aSQLtext : string);
var MyQuery : TSQLQuery;
      TransAction : TSQLTransAction;
begin
   MyQuery := TSQLQuery.create(nil);
   TransAction := TSQLTransAction.create(nil);
   try
     try
        Transaction.database := aConn;
        MyQuery.database := aConn;
        MyQuery.transaction := Transaction;
        MyQuery.SQL.Text := aSQLText;
        Transaction.StartTransaction;
        MyQuery.ExecSQL;
        MyQuery.applyupdates;
        Transaction.commit;
     except
        Transaction.rollback;
     end;
  finally
    MyQuery.free;
    Transaction.free;
  end;
end;

In Dutch we say: "Je maakt van een mug een olifant".