On Tuesday 18 April 2006 08:25, Alexandre Leclerc wrote:
> 2006/4/17, johnf <[EMAIL PROTECTED]>:
> > Or is it better (what a word):
> >
> > sqlunit
>
> If you have a 'sqlunit' that handles all the sql stuff of you
> application, be object oriented in your concepts. Iwould have only one
> function in the sqlunit to close the sql object(s) with proper checks.
>
> If you have an sqltransaction in each form (which looks like), simple
> have the procedure in the form or in a descendent of the form.
> TMySQLForm = class(TForm) // stuff your sqltransaction object in it
> and the procedure. Then inherit from the TMySQLForm
>
> Another simple way is to avoid such a function for a simple task like
> that. You could simply execute the code sqltransaction1.active:=False;
> in the OnDestroy of the form. With the TMySQLForm example concept it
> would be a good idea too. Avoid the procedure for such a simple task.
> It is like bloat code ;)
>
> Best Regards.
>
> --
> Alexandre Leclerc
Thanks for answering. You are right the task was very simple. I used the
code as an example because in fact I'm having issues with understanding the
OOP involved and how the FPC compiler works. It seems that having one call
would be the OOP thing to do. But I noticed that making the call increased
the size of the code and I wondered if the execution speed would suffer
because of the call. In general I would say that the SQLdb is not OOP in its
use. PQConnections,TSQLTransactions and TSQLQuery work best if they are
placed on the form and not created at runtime. I'm not sure if this is
because my inexperience with FPC (the way I coded it) or because of the way
SQLdb was designed (maybe the way Delphi was designed?).
In the Visual FoxPro world I normally would have an object (class) that is
placed on the form to handle all interaction with the data as required. But
so far I don't understand how to do this with the SQLdb controls. I could
create a class to create and set all the SQLdb controls in code but I don't
understand how to add it (the class) to the forms. Even if I did create the
class I don't see the advantage over just placing the SQLdb controls directly
on the forms. OOP for OOP sake does not make much sense. Placing the
TSQLTransaction on the form handles all the 'Begin' and 'Rollback' issues and
infact by placing a PQConnection on each form creates a new connection to the
database - therefore, the database is then responsable for any data locking
issues. What could easier - I don't have to worry about record locking
except within the forms access. So you can see I have questions about how
data is accessed.
I did notice that there is a framework that is available (started with a oT -
something) for FPC. But I noticed that it's main purpose is to support
different database engines with the same code base. Not what I was looking
for. Anyway, I keep learning more about FPC and Lazarus daily.
John
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
