'scuse me but isn't that just like the example I originally sent you?

>Here is the piece of code from my colleague's code:
>

>IF !plFailed AND lnDupeCount <> lnTotal && Batch Transaction
>	LOCAL llUpdate
>	BEGIN TRANSACTION
>	llUpdate = TABLEUPDATE(.T., .T., "load_patients")
>	IF !llUpdate
>		pcAlias = "load_patients"
>	ENDIF
>	IF llUpdate
>            ...
>	IF llUpdate
>		END TRANSACTION
>	ELSE
>		ROLLBACK
>		LOCAL ARRAY laError[1]
>		LOCAL lcError
>		=AERROR(laError)
>		lcError = [ Error: ] + ALLTRIM(STR(laError[1])) + "," + ;
>			[ Message: ] + ALLTRIM(laError[2])
>		=Log_error(lcError, pcAlias)
>	ENDIF
>ELSE
>	LOCAL lcError
>	IF VARTYPE(poException) = "O"
>		lcError = [  Error: ] + ALLTRIM(STR(poException.ERRORNO)) + "," + ;
>			[ Line No: ] + ALLTRIM(STR(poException.LINENO)) + "," + ;
>			[ Message: ] + ALLTRIM(poException.MESSAGE) + "," + ;
>			[ Procedure: ] + ALLTRIM(poException.PROCEDURE)
>		=Log_error(lcError, pcAlias)
>	ENDIF
>ENDIF
>

>
>>Hi,
>>
>>>Thanks a lot, Viv. Here is my colleague's logic: we process the stage tables and make changes in a bunch of our main operational related tables. Then we're saving all the changes made. We need to do that in the transaction because we can not have some tables saved changes and some don't. Since you confirmed the problem it means that we need to make sure to do imports when we don't have users in the system.
>>
>>Surely it should be possible to keep the execution time of the code within the TRANSACTION.... END TRANSACTION to a reasonable limit. In your original post you showed the following code:
>>

>>begin transaction
>>  llUpdate = tableupdate(.t.,.t.,"First Table")
>>  if not llUpdate
>>     rollback
>>     tablerevert all the changes done previously
>>     close the process && That logic is done in a separate method
>>  endif
>>  ...
>>end transaction
>>

>>What happens in the 'close the process' method and the .... section that takes so long?
>>
>>Regards,
>>Viv