Subject | RE: [IBO] Transaction Advice Needed |
---|---|
Author | Tim Ledgerwood |
Post date | 2004-07-20T13:35:46Z |
//make sure the transaction is committed and closed
IBQry_InsertQry.Transaction := IBT_Insert;
Also, I seldom use "dynamic" SQL. In other words, I will have a separate
qry object for each kind of insert that I do - so the transaction will be
"static" - the transaction will never need assigning, as it is already
assigned.
The only advantage I have ever seen to using "dynamic" sql - in other
words, assigning the SQL string at run - time - is that you can group your
SQL together in one PAS file.
The other place I have seen it used is to allow the user to "build" a
dynamic query or "build" his own SQL string. (Like I think Crystal Reports
allows you to do). I don't like giving the user that amount of control ... :-)
Other than that, with parameters and column objects etc.., etc., etc., -
all the other stuff linked to a dataset - I think it is more work than it
is worth to do dynamic SQL.
And in any case, I will generally use a stored procedure rather than a
query. The queries will either be "execute procedure XYZ (P1, P2, Pn)", or
"select * from XYZ (P1, P2, Pn)"
Regards
Tim
At 03:21 PM 20/07/2004, you wrote:
IBQry_InsertQry.Transaction := IBT_Insert;
Also, I seldom use "dynamic" SQL. In other words, I will have a separate
qry object for each kind of insert that I do - so the transaction will be
"static" - the transaction will never need assigning, as it is already
assigned.
The only advantage I have ever seen to using "dynamic" sql - in other
words, assigning the SQL string at run - time - is that you can group your
SQL together in one PAS file.
The other place I have seen it used is to allow the user to "build" a
dynamic query or "build" his own SQL string. (Like I think Crystal Reports
allows you to do). I don't like giving the user that amount of control ... :-)
Other than that, with parameters and column objects etc.., etc., etc., -
all the other stuff linked to a dataset - I think it is more work than it
is worth to do dynamic SQL.
And in any case, I will generally use a stored procedure rather than a
query. The queries will either be "execute procedure XYZ (P1, P2, Pn)", or
"select * from XYZ (P1, P2, Pn)"
Regards
Tim
At 03:21 PM 20/07/2004, you wrote:
> > I don't use IBO Objects at all. (yet) :-) So I can't give you specific
> > advice - but I can tell you what works for me.
> >
> > I use the IB objects. (Yes, they are different). I will almost
> > always have
> > a TIB_Insert transaction, a TIB_Select transaction, a TIB_Insert
> > txn and a
> > TIB_Update txn. In other words, a data module will have at least 4
> > transactions on it.
> >
> > In some cases, especially regarding selects, there will be more
> > transaction
> > objects on the data module. The bottom line for me is that I will almost
> > NEVER have two objects sharing the same transaction object at any
> > one time.
> >
>
>if you use IB_Queries - how do you make the update and insert and delete SQL
>commands use different trasnactions?
>Alan
>
>
>
>
>___________________________________________________________________________
>IB Objects - direct, complete, custom connectivity to Firebird or InterBase
> without the need for BDE, ODBC or any other layer.
>___________________________________________________________________________
><http://www.ibobjects.com>http://www.ibobjects.com - your IBO community
>resource for Tech Info papers,
>keyword-searchable FAQ, community code contributions and more !
>
>
>Yahoo! Groups Sponsor
>ADVERTISEMENT
>
>
>----------
>Yahoo! Groups Links
> * To visit your group on the web, go to:
> *
> <http://groups.yahoo.com/group/IBObjects/>http://groups.yahoo.com/group/IBObjects/
>
> *
> * To unsubscribe from this group, send an email to:
> *
> <mailto:IBObjects-unsubscribe@yahoogroups.com?subject=Unsubscribe>IBObjects-unsubscribe@yahoogroups.com
>
> *
> * Your use of Yahoo! Groups is subject to the
> <http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.