IMatch 3.6.0.42 and later versions give you access to the internal transaction processing in the database. This new feature enables you to have an extra layer of security in your scripts and it also may improve the performance of your scripts dramatically.
A transaction is how IMatch processes changes to the database. All changes are said to be wrapped inside a transaction. All changes made to the database within a transaction can either be committed (made persistent) or rolled back (undone). By default, if the changes are not committed explicitly, they are rolled back. No trace of the change remains in the database, not even when IMatch or Windows itself crashes.
IMatch performs all the transaction logic in the background and you normally do not need to deal with it. An exception are scripts where you require an extra layer of security. And of course scripts which run many updates against the database. IMatch cannot know that your script is going to perform many updates and thus it cannot apply the internal optimizations as needed.
You can gain much better performance by wrapping the relevant parts of the script in a database transaction. IMatch streamlines database operations within a transaction and minimizes disk access and database changes.
Transaction Methods
Transactions are provided by the Database scripting object. There are two methods:
BeginTransaction {[true|false]} (Default is False)
This method starts (opens) a transaction. The parameter controls whether changes to the database are automatically committed or rolled back if your script does not call EndTransaction.
When you stop your script in the debugger, this parameter will control whether changes are written to the database or not. Otherwise stopping or aborting a script with the debugger will roll back all changes made to the database automatically. Which may cause problems, see below.
Do not nest multiple transactions! Do not call BeginTransaction again when you have already started a transaction.
EndTransaction {[true|false]}
This method ends (closes) a transaction. If you use true as the parameter, changes are made persistent in the database. Use false to rollback (undo) changes. When your script does not explicitly call EndTransaction in a script, IMatch will automatically undo all changes by calling EndTransaction false internally.
This may lead to problems and side effects – see the sections on Pitfalls and Risks below.
Using Transactions
To use a transaction, include the following statements in your script:
dim db as Database set db = Application.ActiveDatabase db.BeginTransaction dim iset as Images set iset = db.ActiveSelection dim i as Image for each i in iset ' Statements which update the database... next i db.EndTransaction true ' Use false instead to undo the changes made
Even if you don’t intent to undo changes, wrapping the loop in a transaction will allow IMatch to optimize the inner processing, resulting in a much improved performance of all statements which modify database contents.
Pitfalls and Risks
If you use a transaction, you can undo all changes made to the database since the call to BeginTransaction. But calling EndTransaction false to rollback changes will not undo other changes made by your script.
For example, if you have added or removed files from your disk in the script or changed metadata in files, these changes cannot be undone by a database transaction.
Even worse, if you undo a call to RemoveImage in the database, but your script does not also restore the physical image file on your hard disk, the database will no longer match the layout of the file system.
In many cases you only manipulate database objects and hence using transactions are safe to use and speed up scripts considerably.
But it’s your sole responsibility to use transactions in the correct way. Using transactions gives you more control over the inner workings of the IMatch database and they make your scripts run much faster. But using them also requires some extra care when writing scripts.