All

This is a "What do you guys do to handle this issue below" kind of post... By the way, I'm using IIS DLL's for my backend and newest EWB build.

So I'm not using Auto Transactions. I call StartTransaction myself. It's not desirable to commit every change after they occur due to network lag. So on one dialog I have about 15 datasets for the user to do various inserts, updates and deletes on various tables. Here is the catch. Say there are 10 database operations that is needed to be sent to the server via a Database.Commit statement. All is fine off course if there are no errors triggered by the server that uses the EWBDatabaseAdapter.Commit() to execute the transactions. Below are a senario...

DB Operation 1: Successful
DB Operation 2: Successful
DB Operation 3: Successful
DB Operation 4: Successful
DB Operation 5: NOT successful due to a FK constraint. (delete)
DB Operation 6: Will not executed due to the error in previous statement
DB Operation 7: Will not executed due to the error in previous statement
DB Operation 8: Will not executed due to the error in previous statement
DB Operation 9: Will not executed due to the error in previous statement
DB Operation 10: Will not executed due to the error in previous statement

And so, an OnCommitError is triggered by EWB as the server will then send a non 200 code back to flag the error. Here is where the problem occurs. Obviously, the failed transaction will end up in the Pending request queue. If I try any other commits, this failed transaction will always be sent to the server first. Is this correct? Hence, no more edits, inserts and deletes can be executed by the user. Ok, I can call the CancelPendingRequests to flush the failed transaction. However, then DB Operations no 6-10 mentioned above will be lost right?

So my question is. What is the best way to handle this? Is taking trips to the server for every singel operation the only way to prevent this? Can the EWBDatabaseAdapter.Commit() be told to continue executing queued operations after a failed one? In that case, how to I know what operations failed?

I would highly appreciate some pointers on how to best handle this as I'm sure you have experienced similar issues earlier when sending multiple operations in one commit from EWB.

Thanks

Eivind

Eivind wrote:

> So my question is. What is the best way to handle this? Is taking trips to the server for every singel operation the only way to prevent this?

I am not sure if you are using the WebBuilder server, or your own, but the core here is that you should, in my opinion, be doing everything in one call, one transaction. The lag talking to the server will be big, and you don't want to have more than you need to to achieve anything. For example, you shouldn't get all 100 items in a list one at a time, you would get one response with all 100.

I have been doing some ASP.Net coding recently, and was surprised at how "instantly" the data could be fetched from the database on another computer, even while stepping through in the debugger. I'd step over a call to get hundreds of objects filled by the ORM, and there was no pause. The cost is pretty much in the client to server part.

--

Matthew Jones

Matthew

Yes, on this system I will try to get a bulk of operations into one transaction as it is a time diary system where there are a lot of input. For example: 00:00 - 01:34 Task 1, 01:34 - 03:44 Task 2, etc. Dont want to fire a request to the server every time. Also my server is in the Azure cloud so there are a lag. By the way I'm using Webbroker DLL's plugged into IIS.

The "issue" as described above is when there are many operations in one transaction and one of them fails due to some DB constraints. The following operations after the failed one I have not found a way to  recover as I would have to call Database.CancelPendingRequests to be able to continue.

Eivind,

Transaction reconciliation is something that is coming in EWB 3, along with the ability to specify that certain columns be echoed back to the client for generated/identity/autoinc columns.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

Transaction reconciliation is something that is coming in EWB 3, along with the ability to specify that certain columns be echoed back to the client for generated/identity/autoinc columns.

Eivind:
Just to catch up on this post. It would be awesome to the get transaction reconciliation in EWB 3.0. In the meantime until this "goodie" comes out, can I do the following:

Create a new instance of TDatabase, lets call it TDeleteDatabase. Then temporary assign this TDatabase instance to an existing TDataSet and perform and commit delete operations. That means I can have separate calls to Commit with only specific delete statements that will not obstruct other insert / update commits. Then after a delete commit statement has been committed or rolled back due to an error set the TDataSet back to be owned by the original TDatabase instance so other operations can be performed on it again. Can this be done after a DataSet is created, or can the owner Database only be set during creation of the DataSet?

Tim since Eivind is using Webroker ISAPI DLL with IIS how would this work (reconciliation and echo) with EWB 3?  

I would expect the Transaction reconciliation and echo back is built into your EWB Server.

Will this be documented so we can emulate the same capability in an ISAPI DLL or our own Servers?

Walter

Walter,

<< Will this be documented so we can emulate the same capability in an ISAPI DLL or our own Servers? >>

Yes, the API will be documented, as it is now.  There's really not a lot of changes - primarily some minor modifications to the URLs and this echo feature.

Tim Young
Elevate Software
www.elevatesoft.com