Eivind,

<< In my case, one of my EWB apps is a personnel performance appraisal
system that runs on oil and gas platforms and vessel with very slow and
lossy satellite internet. The user would typically get a link on his email
and click on that link to open the EWB app. There the user click a bunch of
radio buttons and write some comments. At the end, the user will submit the
data to the server. Due to the nature of slow satellite internet, the commit
operation can take up to 30 seconds to complete. It's critical that the user
stay put and and wait for a confirmation, or wait for an error to pop up so
he can retry. After the user presses the commit button, I will show a
spinner and a please wait message. All users that work on a oil and gas
platform are used to this and accept the nature of this internet connection.
I simply cannot just tell the user that the data is saved immediately as he
will then close the browser and move on. I need to show him a progress and
have him wait for a confirmation.

I would also appreciate a call back function when all commits are successful
instead of having a TTimer poll the PendingCommits  and close the spinner
when it reaches 0. >>

Yes, I see where you're coming from now.  I'll add an event for the success
of the pending commits.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

Walter,

<< Random thoughts - so I Commit the current client dataset transactions.
At the Server when the transactions are applied to the database a number of
stored procedures fire that generate new data and new records in other
tables that I now want to show in the browser.  Could be a bunch of
statistical data.....

When do I know to Database.Load(NewStatsData)? >>

Also a good point.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

On 5/19/2015 10:28 AM, Tim Young [Elevate Software] wrote:
> Well, the general idea is: if the connection is completely gone, then it
> doesn't matter since the application is now useless.  If the
> connection can be restored at any point, then the commits can be retried.

Thanks - i was trying to see if there is an easy way to force an "app
reset".

Once can do so inside the app but then I'd need to make all parts of the
app aware of this and properly call appropriate code (i.e. close and
free all forms and reset any non-visual objects and states, cancel any
pending requests, etc).

Asking user to close and reopen browser would work but is not-elegant.

Navigating back to app own URL thus forcing browser reload might be an
option - need to test.

Not sure if Phonegap/Cordova have some other methods of resetting since
there the reload would not really work same way.

Raul

Raul,

<< In general case just load data right after commit without waiting. The
server requests are serialized and queued by Database so the load will not
happen until commit completes (since it was in the queue first). >>

Actually, it's not that simple.  The server request queue *still* executes
the next server request if the preceding request experienced an error.  It's
done this way to allow the caller to determine how to respond to any error
condition instead of the queue.

But, if this is an issue, I can certainly change it so that the queue keeps
requests in the queue until successful or cancelled.  The existing Cancel
method allows you to specify whether you want to keep executing further
requests.

It may be that I just need to do the above change and expose more of the
queue functionality in the database layer.

Tim Young
Elevate Software
www.elevatesoft.com

Raul,

<< Not sure if Phonegap/Cordova have some other methods of resetting since
there the reload would not really work same way. >>

That's a good point.  I was just thinking Ctrl-F5, but that may not work
with PhoneGap.

Tim Young
Elevate Software
www.elevatesoft.com

Raul/Eivind,

Okay, I've fixed this all now so that it operates as expected, and the
changes will be in build 9 of the preview going out today.

1) All requests, commits and loads, are queued up in the same server request
queue, so you can now do what Raul described in terms of queuing up loads to
occur after a commit.
2) AfterCommit is only fired *after* a successful commit request (if
transaction level is 0).
3) There is now a NumPendingRequests property that encompasses all pending
requests (loads and commits).
4) There are now CancelPendingRequests and RetryPendingRequests methods for
dealing with the pending requests.

In addition to the dataset layer, the server request queues now operate in a
similar manner (of course).  Therefore, if there's an error with a server
request in a TServerRequestQueue instance, the queue will stop at that
request until the queue is restarted with the ExecuteRequests method, or the
current request is cancelled via the CancelRequest method, or
CancelAllRequests method.

I've included a new Transactions example project with EWB that shows how to
handle all of the nested transactions and commit retries.  You can see it in
action here:

http://www.elevatesoft.com:8081/transactions/transactions.html

Of course, you can't shut off the web server to test the retries, so you'll
have to disable your network adapter instead to test them.

Tim Young
Elevate Software
www.elevatesoft.com

Thanks Tim!

Highly appreciated

Eivind




"Tim Young [Elevate Software]" wrote:

Raul/Eivind,

Okay, I've fixed this all now so that it operates as expected, and the
changes will be in build 9 of the preview going out today.

1) All requests, commits and loads, are queued up in the same server request
queue, so you can now do what Raul described in terms of queuing up loads to
occur after a commit.
2) AfterCommit is only fired *after* a successful commit request (if
transaction level is 0).
3) There is now a NumPendingRequests property that encompasses all pending
requests (loads and commits).
4) There are now CancelPendingRequests and RetryPendingRequests methods for
dealing with the pending requests.

In addition to the dataset layer, the server request queues now operate in a
similar manner (of course).  Therefore, if there's an error with a server
request in a TServerRequestQueue instance, the queue will stop at that
request until the queue is restarted with the ExecuteRequests method, or the
current request is cancelled via the CancelRequest method, or
CancelAllRequests method.

I've included a new Transactions example project with EWB that shows how to
handle all of the nested transactions and commit retries.  You can see it in
action here:

http://www.elevatesoft.com:8081/transactions/transactions.html

Of course, you can't shut off the web server to test the retries, so you'll
have to disable your network adapter instead to test them.

Tim Young
Elevate Software
www.elevatesoft.com