It's time to say goodbye to the classic navigation system. Any comments?
Classic Navigation seems to have one advantage. It will have fewer "lost updates" won't it. Under dataList navigation, since the query is not rerun each page, isn't is possible that a user (A) would have outdated data if another user (B) had updated a record that is in the record set being used by user A?
I am all in favor of the new nav system (+1) but I think it should be made clear to people what the side effects may be.
As you can see from an earlier discussion below, Dirk suggested adding a timestamp and and re-reading it before doing an update to see if the record had been touched. It would be nice to have this offered within DBForms as an option that users could select. I wonder if it would be possible to come up with a servlet that does the same thing in application scope that tracked updates by table and key and timestamp and that could be checked instead of running a query. (problems would be memory consumption and the need to throw out records in the servlet that are older than the oldest open record set).
> If two users access the same page and both make changes -- let's say user #1
> updates first -- then user #2 will see the information entered by user #1
> and the changes that user #2 entered will be lost. Is this correct, it
> seems to be how DbForms is working?
> Yes, dbforms creates new database connection each time a form
is send to the server, so it cannot use any build in database locking
mechanisms. What you describe is a typical 'lost update'
that can occur if the system does not care about that. The reading of the old value and updating to new value of a row is
not part of the same transaction.
I would not recommend to implement any locking mechanisms
within dbforms, nobody will know if someone will ever click the update buttons or just shuts down his computer. Instead
you could do something like that:
- add a new column 'last_update' of type timestamp to the table
- automatically set this column to 'now' whenever you update or insert,
could be done using interceptors
- before you do an update you reread the row again and compare that
timestamp value with the one you get from the form or maybe have stored
before as a session attribute. If it differs, you know someone
else has touched your row in the mean time, you might generate
an error...
I think that should be possible using interceptors with current dbforms.
To include this functionality within dbforms as a standard offer,
more work would be needed. It must then also be possible to activate or deactivate this as needed.
Another problem of this approach is the need for the extra column.
Sometimes you are not allowed to change the database schema to support
extra functionality within a frontend.
Regards
Dirk
It's time to say goodbye to the classic navigation system. To fix a bug in
adding a new value in an subform i must make a change that will not work
under the classic navigation. Looking to the changes in in DbFormTag - how new position is calculated i
will suspect that classic navigation will make an error, too.
Fix can only work for one system...
Has anybody tested navigation in the classic system? Is navigation working
correct? Or are you all using the datalist system?
Any comments? Or just say godbye?
Regards, Henner
-- Shawn
Happily using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ DbForms Mailing List
http://www.wap-force.net/dbforms
