Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 6 of 6 total |
update and delete with transactions |
Fri, May 23 2008 8:19 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent Link |
Lance Rasmussen Jazzie Software 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 PM | Permanent 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 PM | Permanent Link |
"Eduardo \(HPro\)" | Lance
Thanks for your explanation. Eduardo |
Sat, May 24 2008 2:50 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Tuesday, September 17, 2024 at 04:19 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |