button Update database

JDS

Member
Joined
Mar 12, 2006
Messages
7
Programming Experience
1-3
Hi,

I am just starting to learn VB.NET and would very much appreciate a little help. I went through several books - got the Wizard version of db connections, datagrid, binding context, etc. I prefer the programmatic version of knowledge. Programmatically I set up the db connection, estab the data adapter and data set. Access is the db with only one table for now. All I want to do is update a record-call the record NAME. The following is the coding I have done to establish the connection, data adapter, data set, data table, etc.

I just want to have a button that I can have the working code to update the database via the dataset. Any help is appreciated.

Thanks,
John

PrivateSub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) HandlesMyBase.Load
Dim conn AsNew OleDb.OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=c:\people.mdb;User Id=;Password=;")
Dim da AsNew OleDb.OleDbDataAdapter
Dim ds AsNew DataSet
Dim sqlQuery AsString
sqlQuery = "Select * from [Names]"
da.SelectCommand = New OleDb.OleDbCommand(sqlQuery, conn)
'If I want to populate a datatable object outside of the DS object
'I can Dim a datatable and set it equal to the particular table (called "Names")
'which I added to the dataset (done on the right side of the equation)
'Supposedly, specifying the datatable name in the fill method of the dataset object
'will create and load the datatable so I don't have to explicitly use an "Add"
'method as I have done below.
Dim Names As DataTable = ds.Tables.Add("Names")
da.Fill(ds, "Names")
Dim dRow As DataRow
Dim dCol As DataColumn


ForEach Names In ds.Tables
ForEach dRow In Names.Rows
ForEach dCol In Names.Columns
Console.WriteLine(dRow(dCol))
fName.Items.Add(dRow(dCol))
Next
Next
Next
fName.Text = dRow(dCol)
fName.Text = dRow.ItemArray(1)
EndSub
EndClass
 
I went through several books - got the Wizard version of db connections, datagrid, binding context, etc. I prefer the programmatic version of knowledge.

Makes it very hard work though, doesnt it? Writing all your code by hand and stuffing it into Form Load makes things difficult to maintain, and not very efficient. There are additionally, easier ways to fill a list style controls like you seem to have here (fNames?) rather than copying data out of a database into a datatable, and then out of a table into a collection that is attached to the control.

If you went the "wizard" way, you would probably do this:


myTableAdapter.Fill(myDataSet.MyDataTable)
fNames.DataSource = myDataSet.MyDataTable



If you want to see the code behind it all for the "knowledge" it can impart, you can read the DataSet.Designer.vb file, in the same way that if you want to gain the knowledge of how to lay out a Form manually and position all the controls, you can read Form1.Designer.vb - the difference is that the "wizard" way helps you write good, efficient, maintainable, well encapsulated code and spend more time on writing the program than writing the boring, tedious data access code
 
Update

Thank you, appreciate the reply. Where I work prefers a thorough knowledge of coding - more extensive than that allowed by using the Wizard. After gaining the knowledge then the Wizard may be employed as convenient.

Thanks again,

John
 
Sure, sure.. an understandable concept. If they gave you any stick about it then you can point out that it's not so much of a wizard, but a graphical designer to what is essentially repetitive code. The Form Designer and the DataSet designer have similar aims and do a good job; it would be hypocritical of them to criticise you for using the DataSet Designer but allow you to use the Form Designer.
With the DS Designer you are still required to write your own SQL statements, put the parameters in and in some cases, map the parameters to the underlying data table columns through use of the property designers - all in I feel it adds to the development experience by allowing you to focus on the important things, like crafting nifty SQLs, and leave the repetitive work that takes time but doesnt represent a significant part of actual business logic

Good luck!
 
Back
Top