When do you write to Database

Targets Web
1

Hi, I have done some web apps now with database for storing the info. But you guys and girls, when do you write to the database…

  1. With a dedicated “Commit” button.
  2. When focus is lost for a control i.e. TAB button on keyboard
  3. During typing in a field (valueChanged event.)

I like no 3 best, and sometimes I use 2. But never ever 1 … I don’t want to have a commit button. I don’t want to go in/out of write modus…

Also the search field has it’s own button for doing the search… I like more using a regular text field and on value changed and if length is more than 3, then do search…

Opinions ?

2

#3 is probably the worst for a web app because every keypress event gets sent to the server and gets saves. It’s a bad strategy in a real web app. #2 is ‘better’ but still all those events get sent to the server for processing. #1 is probably the best but if the connection is lost there’s no way of recovering the data in the controls after a certain amount of time.

Keep in mind that a web app and a desktop work different with events and lag time. While you’re debugging your web app locally there is essentially zero roundtrip time between the browser and the app that once you get it into to the real world will be there.

3

Always #1. Never #2 or #3.

4

Hi Bob, I do all my debugging from local machine in Norway, and the database is always on my amazon machine. So I try to test/debug in real-life data transfer.

About the 1. I have found that it does not send each time you press a key, you have to wait almost a second before the value-change triggers, and if you are a ok typer, the value-change should not fire that many times. I normally prefer #2, as I would like to have the data written as soon at the person is typing it…

5

To each their own.

6

[quote=491629:@Helge Tjelta]Hi Bob, I do all my debugging from local machine in Norway, and the database is always on my amazon machine. So I try to test/debug in real-life data transfer.

About the 1. I have found that it does not send each time you press a key, you have to wait almost a second before the value-change triggers, and if you are a ok typer, the value-change should not fire that many times. I normally prefer #2, as I would like to have the data written as soon at the person is typing it…[/quote]

So basically you already have your mind made up :wink:

The one thing I would not want to deal with your choice is having to delete data that has already been written to the database but the user then deletes while still typing input. Having to change from an insert to an update while the user is still typing does not seem like fun to me either.

7

I think I stand firm on #2. Because then I just write info about one field and not all fields in my display…

I just had to know what you all are doing… looks like I’m not going with the crowd here… But thanks for chiming in :slight_smile:

Also, I use valentina as DB, and their own API. My lostfocus is therefore.

session.cursor.field(“name_of_field”).setString(my_textfield.text)
session.cursor.updateRecord()

Thats it for updating a database-table, when using lostfocus. The cursor is ServerSide.

8
  • Turn on your network monitor and see how much traffic this generates
  • Try using your app on a very slow connection and see how painful it is to have to wait for a server response
  • Terminate your network connection while editing a record and see how your app recovers
  • see how many users you can get up on the system before your server gets overwhelming with the constant updates

We take No. 1 to try and avoid those kind of issues as much a possible.

9

In Chrome and Firefox you can set the “Throttling” to emulate such conditions.

10

Yep, I found it, super tip!!!

I did set the app to use Good 2G, and no drop in performance for me as user…
Most field was set to update on value changed, and no slower UI. But I guess I’ll go with lostFocus instead, just to minimize the load, for me as a user, these text transfer to my DB, has no slowdown on Good 2G… and at least here in Norway you get good 4G mostly everywhere.

11

[quote=491742:@Helge Tjelta]Yep, I found it, super tip!!!

I did set the app to use Good 2G, and no drop in performance for me as user…
Most field was set to update on value changed, and no slower UI. But I guess I’ll go with lostFocus instead, just to minimize the load, for me as a user, these text transfer to my DB, has no slowdown on Good 2G… and at least here in Norway you get good 4G mostly everywhere.[/quote]

I have been working with Xojo Web for only around 6 months so I’m no expert, but I’ll offer my 0.02 of advice: When I started working on this project I too had some on lost focus events where I was only changing the text to uppercase (as needed in this project), I thought the latency was not bad but that was my opinion only. Then I had some users test a prototype and they all complained about the latency, granted this testers were mostly used to desktop apps and have unrealistic expectations of speed in a web app it was enough feedback to make me rethink about my implementation.

12

I’ll keep an eye on this. But I’m more concerned about the size of an app, as it takes some time to just open it…

13

[quote=491729:@Rick Araujo]In Chrome and Firefox you can set the “Throttling” to emulate such conditions.

[/quote]

I know, but it often does not create the same impact, especially for apps as opposed to websites.

14

I always hear my customers sigh with relief when I explain to them “when you think you’ve messed up, just hit the cancel button. Only when you hit the save button will the changes be written to the database”. This is especially true if the window is really complex.

15

+1. I also sometimes have a “Validate” button when calculations or other somplex processes need to be shown on the UI once specific actions are made (most times, no need for the validate button, it can be done automatically), and a “Save” button to commit the data to the database.