Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Again, troubles with CursorAdapter
Message
From
14/08/2003 01:30:19
 
 
To
13/08/2003 22:48:11
Peter Wagner
Point Informática Ltda.
Limeira, Brazil
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00819734
Message ID:
00820020
Views:
18
Peter,

Thank you so much. In the mean time, I got some sleep, so I see things a little different now. Last night (after I posted my previous messages) I found something interesting about CA vs RV: if SQLSERPROP(handle,"Transactions",1) is in effect, the TABLEUPDATE("CursorAdapter") sends to server a batch of commands, including the update and the following command: "IF @@TRANCOUNT>0 COMMIT TRAN" (I've seen that double-clicking the process in Enterprise Manager and that thingie shows the last command issued. Well... I don't have such command in my code. So it must be the CursorAdapter. I couldn't find any setting to make it stop that. There is no such behaviour in RV, with automatic transactions.

On the other hand: If the SQLSETPROP(handle,"TRANSACTION",2) is in effect, whenever I open a cursoradapter, the server receives a begin transaction command. I guess this is the normal behaviour - the RV behaves identically.

Last night I was fooled by the RV behaviour - i expected CA to be somehow the same, to keep the code compatibility. No luck. Warning for developers: expect to change your code _A_LOT_ if you switch from RV to CA! The transaction created automatically by the first RV using that connection is closed automatically when the last RV is closed. At least, this is happening it my computer. CA, on the other hand, does NOT close the transaction, and it leaves it as is.

Yesterday, late at night, I ended using a code very similar with the one you've posted. The bad thing is I have to change ALL my forms to include that code. All the forms used only for displaying data have to be changed, because now they increase @@TRANCOUNT on server, but doesn't decrease it at form's Unload. And believe or not, I have at this moment 618 such forms in my app - I counted them yesterday. It's an ERP.

Go figure what I think about MS and the programmers there, and how happy I am, AS A PAYING CUSTOMER.


Anyway, thank you so much (and Mark McCassland too) for your answers. It's refreshing to see someone on your side.



>c) I have a diferent aproach to use Transactions with CA as you have and it works fine for me.
>At Server side I have the Stored Procedures for Insert/Update/Delete that CA calls with Tableupdate.
>Heres a simple model.
>
>= SQLSETPROP(nID, 'TRANSACTIONS',2) && MANUAL
>
>IF TABLEUPDATE(1,.T.,table_name)
>   = SQLCOMMIT(nID)
>ELSE
>   = SQLROLLBACK(nID)
>   oConn.GET_ERROR() 		    && Get error from Server..
>ENDIF
>
>
>But CA really could be easier for developers and also needs improvement.
>
>Peter
Grigore Dolghin
Class Software.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform