Best Practices, No AfterUpdate

[4461766964]

VB.NET 2008

Writing a new application to work with an Access database has been like pulling teeth. Having used VB6 I was relatively sure I would be able to figure things out on the fly. I am now to a critical point where my choices will drastically affect the efficiency and size of the application.

Specifically, I am curious if there is a best practices recommendation for capturing user input for new and updated records when working with a database? In VB6 this was simple using control.afterupdate. However, this feature no longer exists. And control.validate fires no matter whether the information was changed or not. Likewise, using control.enter and control.leave for each of my 25 controls would be like writing a small book. My crummy .NET book and all the examples I have found on the Internet encourage the use of an "Update" button. However, this is shocking to me as I would assume most people would like their program to be just like the great and mighty Access... I would never torture my users into hitting an update button each and every time they added or changed something.

As always there are dozens of ways to do this. So what is the most efficient and/or recommended means of capturing an update to any given control? I'm not necessarily looking for code here. Maybe just a direction to head would be good. Thanks

David

 

[cjard]

i dont really understand your post but it seems you and I do things a very different way. for the way i do it, read the dw2 link in my sig, following the "Creating A Simple Data App" link

 

[4461766964]

I guess it is probably a bit old school anymore, but I was taught it was bad to use the intrinsic tools for data access. In fact the VB '05 book I have jumps right into writing your own code and never even covers the steps to add a datasource using the wizard. However, just to see how it would function and what it would look like I created the example application using the Northwind database. I was very amused to find that the records navigation toolbar VB created to work with the data also has a "Save Data" button on it.

What I am looking to do is save information to the dataset automatically as it is entered into the form, just as Access (2003) would do. I do not want the users to be required to press an "Update" or "Save" button manually.

 

[JohnH]

You can move the save code into FormClosing event and run it if yourDataset.HasChanges. In that case you can also ask user for confirmation if not autosave option is enabled.

Note that Ado.Net uses a disconnected architecture, communication with the external database/service is considered expensive and should be avoided when not necessary.

bad to use the intrinsic tools for data access

Visual Studio is a visual development suite with strong visual designers, the visual aspect does not mean looking at code Defying visual data access development tools is no different than doing the same for forms development, except you have to write a lot more code. That's Notepad hilariousm. The question is of course about using the right tools for the job, be it designers or manual code or combinations, so you have to learn both to be able to choose in circumstances.

 

[4461766964]

Are you saying I'm hangin' on to the past?

The database is local...and small, but I finally understand the reason for the way VB works with data now. Thank you both for your help. I guess the only drawback would be a power outage if you had added or updated numerous records. I'll just write the code into the form exit and get used to the idea of the information not being saved until then.

Using the datasource/designer tools were interesting and remarkably simple. Now I know how to use them if I decide in the future to partake in a similar adventure.

 

[Stonkie]

One thing I'm not sure you understood is that the dataset is not the database. The data is sent to the dataset automatically when you bind your DataGridView to its table so the DataGridView is detached from the data's internal representation. The dataset is a local cache for the distant database.

From the dataset, you will then run

tableAdapter.Update(dataset.MyTable)

which is the line that calls the necessary queries to send your data back to the database. But if there were no changes in the dataset (and consequently in your DataGridView), the update operation will not call any query on your server.

That way, you can call the update method as many times as you need pretty much anywhere. You could bind to another event (I don't want to advance the DataGridView's CurrentCellChanged event but I think it works). Just note that you can't call it when handling some of the DataGridView's events because the data is in the middle of going back/forth between the DataGridView and the dataset.

It may be a little less efficient (because the table adapter is usually set to refresh data when it updates something to retrieve auto generated fields), but if simple is your mojo, you can optimize when scaling is required.

The designer in Visual Studio is so advanced that in the last year I can safely say I've learned more about the designer than the programming language itself. You really gain in productivity and you simplify the application by making it easier for someone else to understand.

 

[4461766964]

Thank you for making sure. That's important. I believe I do. Although I admit, the words: database, dataset, dataadapter and so forth are starting to blur together into a tingly mental numbing.

 

[pettrer]

if simple is your mojo, you can optimize when scaling is required.

The designer in Visual Studio is so advanced that in the last year I can safely say I've learned more about the designer than the programming language itself. You really gain in productivity and you simplify the application by making it easier for someone else to understand.

Yes, this is what I'm trying to accomplish too. It's so easy in Asp.Net to use the visual stuff and then get the coding part to be concentrated on "true" coding. I mean - filling tables manually really sound like good old Asp...

Unfortunately there seems to be very little information on how to do things using dragn'n'drop etc (I'd be glad for someone answering my two previous posts on this and best practice).

All the best
Pettrer

 

[JohnH]

Unfortunately there seems to be very little information on how to do things using dragn'n'drop etc

Really? The Data Walkthroughs and the "How Do I" videos (see Forms over data) from MS mostly show how to use the visual designers.

 

[cjard]

Thank you for making sure. That's important. I believe I do. Although I admit, the words: database, dataset, dataadapter and so forth are starting to blur together into a tingly mental numbing.

datareader reads from a database
dataadapter uses a datareader and puts data into a datatable
dataset is a collection of datatables, enables relationships to exist

database = reservoir
datareader = pipe
dataadapter = tap
datatable = washing up bowl
dataset = sink

 

[pettrer]

Really? The Data Walkthroughs and the "How Do I" videos (see Forms over data) from MS mostly show how to use the visual designers.

Hi,
Thanks for the link to the videos - haven't spotted them before. Still, I think this could be done much clearer (as in a book on using as little code as possible when developing Windows forms VB.Net 2.0 applications) in order to fully get people to use the built-in capabilities the correct way.

/Pettrer

PS. Love your Stargate Atlantis quote - hadn't spotted that one either...

 

[4461766964]

LOL They should put that on MSDN!