views:

39

answers:

3

Set the scene:

New to .NET; drinking from firehose

ASP.NET MVC app, SQL Server back

Editable table in browser with a single SAVE button.

User can right-click to add or delete rows.

Table won't ever have more than approx. 30 rows.

My question : I'm saving everything upon the Save button click but would it be better to save row by row, AJAX style, as the user makes updates? I don't like the look of separate buttons for each row, which is why I've designed it this way. Is this mostly a UI issue? Am I missing any technical gotchas here, such as backend failure during the mass saving of the rows?

Additionally, assume I do save the entire table at once, is it better to create an ADO DataTable object or just loop through, inserting/updating each row as I go by calling a stored procedure. I suppose I could add LINQ to the firehose, but that would make this question even less "answerable".

Hope this isn't too opinion based... Thanks for the advice...

Bill

A: 

Assuming you have SQL2005, you could build up an XML document with all of your data rows, then call a single stored proc and pass it your XML. Then the stored proc could save all of the rows at once.

David
An interesting suggestion - I don't know why someone considered it of no use. I'll click it back to 0.
BillB
Sorry, no enough cred to do so.
BillB
+1  A: 

What I've done before with these sorts of big table views is when somebody clicks on a cell they'd like to edit, run some ajax to display a text field with that text, they can edit, then listen to onmouseout and the enter button to send off the ajax request to modify the single row.

When the response from the ajax call comes back you can add a tooltip or something that it was saved, and then change the cell to the new val.

lucas
Hey Lucas - I considered that approach but was scared off by possible Internet latency. If you've done this with an app outside a firewall, has the response time been adequate? (I should have included that it's an Internet app in the scene setting.)
BillB
This particular view-of-a-table was intranet. You can make it work - see google docs version of excel. It all depends on so many factors - latency, geolocation, server, users, technology, etc. of course. It also depends on what the client is comfortable with :)
lucas
+1  A: 

You don't have a huge volume of data here, so saving all 30 rows at the end of the table is a reasonable approach. But you should be prepared for a failure, particularly if you are changing existing rows when it will fail more often due to other apps/users changing the same data. Just make sure that you wait for confirmation from the SQL server that the changes have been committed.

Michael Dillon
Thanks, Michael, it looks like I'll stick with my plan for now.
BillB