Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Transaction behavior
Message
 
 
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Environment versions
Visual FoxPro:
VFP 9
OS:
Windows XP SP2
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01075467
Message ID:
01076129
Views:
31
Terry,

Ok, let's go back to what you have posted:
begin transaction
* all the changes that happend previously
...
* This bit of updating
  llUpdate = tableupdate(.t.,.t.,"First Table")
  if not llUpdate
     rollback
  Else
     tablerevert all the changes done previously && not sure would be necessary if rolling back anyway!
     end transaction 
     close the process && That logic is done in a separate method
  endif
First of all, you can not do tablerevert inside transaction. Secondly, how this code is different from what I have posted and what is posted bellow (the actual code of my colleague). And how your suggestion was addressing the problem I stated? I don't see it, may be somebody else can.

>>>'scuse me but isn't that just like the example I originally sent you?
>>>
>>And this is exactly what I posted from the beginning in the thread.
>
>Oh no it isn't. You had the whole thing bracketed with begin ... end xaction, regardless of the conditional rollback:
>
>>>>>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
>
>
>>If you review your piece of code you'll notice the problem in the logic. I think you accidentally made it reverse.
>
>Can't see a problem with it, don't understand what you mean by "accidentally made it reverse" (made what reverse of what?) and it's very like that below.
>
>Anyway, you've got it sorted now and I still don't see what your probelm is.
>
>Terry
>
>>
>>>>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
If it's not broken, fix it until it is.


My Blog
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform