Hi,
I do not think that is quite correct. The purpose of a Transaction is to maintain database integrity if you are performing multiple operations like insert and delete. If at anytime you get an error along the way you would issue a rollback which will undo anything you have done after you start the transaction. The other advantage is that when you close a transaction, the database will commit the changes to physical file and not retain the changes you have made in memory. If you do not use the transaction mechanism, what the database is doing is performing a transaction behind the scene from the time you open the database and then close the database. So in the case when this was not done, the time to process 30,000 records took a lot of time, I hazard a guess the database was maintaining transaction overhead for the whole 30,000 records. When a transaction was performed say for every 100 records, the database committed the changes and the overhead of maintianing transaction is minimal. You would get a balance of maximum performance by choosing how many records you insert during the time you start and close a transaction, this depends on the device and speed of processing etc etc. My experience is with Oracle database and not with SQLLite. I assume the mechanism of transaction is similar. Cheers Joe --- In [email protected], Hannes Streicher <hstreic...@...> wrote: > > i like to comment on this one, > my guess for the speed difference is: > the difference is not that you are using Transactions or not > but that without using explicit transactions every single query is > wrapped into a transaction causing additional overhead > > > -- > Mit freundlichen GrĂ¼ssen / with best regards > Hannes Streicher mailto:hstreic...@... > -- You received this message because you are subscribed to the Google Groups "nsb-ce" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nsb-ce?hl=en.
