Am Dienstag, 25. März 2003 14:50 schrieb Peter: > Hi all
Hi Peter, > I am doing a web page which has multiple rows from database > in that i am giving modify option thru which user can modify the contents > in each row say like this > > name age > --------- > abc 12 > edf 13 > hjk 12 > > Modify Looks somewhat strange to me. Do I understand right that you have a global 'Modify' button for all of the values currently presented on the screen? This is the way you do it in normal GUI applications, but not on the web. Otherwise, given that such an approach might theoretically work to some degree, you end up with a real multitude of parameters sent to and fro. If I'm right, in fact your forms seem to send the values of unmodified columns anyway, updating the database with the same values as before in that case; makes no difference as long there's no trigger involved keeping track of modification times. Can't really tell from the details given, but normally, one would put a (generated) 'Modify' button at the end of each row, presenting some 'details' form after clicking it where the user may edit the specific entry's data, with a 'Save' button at the lower end which finally sends the modified data to the database, one specific item at a time, and presents some list view of the database contents afterwards. And so on. If you want to provide some 'temporary' persistence, allowing for 'Undo' capabilities, you could provide for that by sending everything to a Collection maintained in Session scope and providing some means in your application saying 'Commit Changes' (a button or something) which finally sends the entire Collection to the Persistence Layer | database. This is kind of what 'cached updates' do in GUI applications, but even there, the advantages (reduced network traffic plus 'Undo' capabilities) have to be weighted against several severe drawbacks (having to keep the cache in sync in a multi-user environment is just one of these; in general, there's a database transaction | locking problem in such 'decoupled' scenarios). In a web appli- cation, in particular, I would generally recommend to keep things as simple as possible: detail form, submit, insert | update, next detail form - an so on. > but the overhead incurred is if i use request.getparametervalues > all the rows even unmodified it returns which in turn is a huge overhead in > database how to detect the rows that has only been modified please do > advice If you directly read from the database, this is the expected behaviour. From the database view, there are no 'modified' values. Either something is (permanently) commited or it's not; there is no 'modified' stage somewhere in-between. A different question is which values the database may present you while a transaction lasts, i.e. as long as the changes are not permanently committed. As each transaction could also result in a Rollback, there's no safety here re- garding 'definite' values; check your database manuals for things like 'transaction isolation'. If your database doesn't support transactions (some versions of MySQL, for example), you won't have to bother about such things, but expect all kinds of inconstencies in the database itself afterwards. > Regards > Peter HTH, -- Chris (SCPJ2) ==========================================================================To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
