Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 6 of 6 total
Thread update and delete with transactions
Fri, May 23 2008 8:19 AMPermanent Link

"Eduardo \(HPro\)"
This doubt I have is the same with DBISAM.

Which of them has the best performance and integrity.

Query.Sql.Text := 'update table set field=content where condition';
Query.ExecSql;

or

Database.StartTransaction;
Query.Sql.Text := 'update table set field=content where condition';
Query.ExecSql;
Database.Commit;

I am using the second approach but because this is a function I always check
what table is involved to put just this into a restrictive transaction.

Eduardo

Fri, May 23 2008 1:41 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Eduardo,

<< Which of them has the best performance and integrity. >>

The second version will always ensure that the commit is one only once,
whereby the first version may flush updates to disk partially during the
execution.

--
Tim Young
Elevate Software
www.elevatesoft.com

Fri, May 23 2008 1:51 PMPermanent Link

Lance Rasmussen

Jazzie Software

Avatar

Team Elevate Team Elevate

Using the transaction approach would insure that everything between
StartTransaction and Commit is run together.

When you are only running one SQL statement, this may be extra insurance,
but not necessary.   If you were needing to run 2 or 3 update statements,
then definately, I would use transaction for integrity.

Lance Rasmussen


"Eduardo (HPro)" <contato@hpro.com.br> wrote in message
news:E9A2F52A-D195-43A0-94FD-FDB305DC41D0@news.elevatesoft.com...
> This doubt I have is the same with DBISAM.
>
> Which of them has the best performance and integrity.
>
> Query.Sql.Text := 'update table set field=content where condition';
> Query.ExecSql;
>
> or
>
> Database.StartTransaction;
> Query.Sql.Text := 'update table set field=content where condition';
> Query.ExecSql;
> Database.Commit;
>
> I am using the second approach but because this is a function I always
> check what table is involved to put just this into a restrictive
> transaction.
>
> Eduardo
>
>
Fri, May 23 2008 2:12 PMPermanent Link

"Eduardo \(HPro\)"
Tim

IOW, I understand the process but these flushes can break integrity if
*AFTER* them some error occurs even with just one "upgrade or delete
statements".

Thanks for clarify this.

Eduardo

Fri, May 23 2008 2:13 PMPermanent Link

"Eduardo \(HPro\)"
Lance

Thanks for your explanation.

Eduardo

Sat, May 24 2008 2:50 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Eduardo,

<< IOW, I understand the process but these flushes can break integrity if
*AFTER* them some error occurs even with just one "upgrade or delete
statements". >>

Yes, which is why I mentioned them. Smiley

--
Tim Young
Elevate Software
www.elevatesoft.com

Image