How to add data to MS Access database with VB.NET? - vb.net

Question

I know this would be really simple but I don't know what is wrong with my code. I have tried several times.
I have two things, Username & Password on my db table. I want to add data to a DataGridView and save it to my db table. I use 2 buttons ADD & SAVE.
Database Table
ID Username Password
1 Zain 12345
2 Admin root
VB.NET Code (as explained in https://www.youtube.com/watch?v=XRVBpTFa3To)
Public Class edmin
Private Sub edmin_Load(sender As Object, e As EventArgs) Handles MyBase.Load
'TODO: This line of code loads data into the 'UserInfoDataSet1.Users' table. You can move, or remove it, as needed.
Me.UsersTableAdapter.Fill(Me.UserInfoDataSet1.Users)
End Sub
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
UsersBindingSource.AddNew()
End Sub
Private Sub Button2_Click(sender As Object, e As EventArgs) Handles Button2.Click
Try
UsersBindingSource.EndEdit()
UsersTableAdapter.Update(UserInfoDataSet1.Users)
MessageBox.Show("Saved")
Catch ex As Exception
MessageBox.Show("error")
End Try
End Sub
End Class

Answer 1

When you add a data file, e.g. MDB or ACCDB, to your project, it becomes a source file. When you run your project in the debugger, your app does not connect to that database. When you build, that source data file is copied to the output folder, along with your EXE, and it's that copy that you connect to at run time. If you go looking in the source file for any data added during testing, of course you won't find it.
This makes perfect sense when you think about it. When it comes time to deploy your application, do you really want to have to spend time cleaning up the database to put it into a state suitable for distribution? By testing against a copy, you keep the source database in pristine condition. When you build a Release version of your app, the clean source database is copied into the Release output folder with the EXE and your users get that clean copy.
Now, when you add the database to your project, its Copy to Output Directory property is set to Copy always by default. That means a new copy is made every time your project is built. If you run your project and make changes to the database, then stop the debugger, make changes to the code and then run the project again, the project is rebuilt and a new copy of the database made, thus your changes disappear. If you run the project twice without making any changes to the code then it won't be built the second time so the changes in your working database will not be overwritten.
What you should do - and what I think Microsoft should have done by default - is change that Copy to Output Directory property to Copy if newer. That way, even if your project gets built, a new copy of the database will not be created unless you have made a change to the source database. That will allow you to keep the same test data in your working database as long as you want. When you do want to start afresh, simply delete the data file from the output folder manually or change the Copy to Output Directory for a single build.
Microsoft caution against this because the source file can change even if you don't make a change to the data or schema it contains. Simply opening the file can affect it and prompt a new copy to overwrite your working directory. If a new copy would be created every time though, I say big whoop. I've rarely seen a data file update when I didn't intend it to. You can read here for more information.
Now, with regards to IDs, your DataTable is going to create a temporary ID when you add a new row. That ID can be used to identify the row, even to related child rows, as long as you use the data in your app without committing it to the database. When you do commit the change, a permanent ID is generated by the database.
Often you don't need that ID right then and there because you won't be using the data right then and there. You won't be using the data again without retrieving it again, in which case you will retrieve the final ID with it. Sometimes though, you do want to retrieve the final ID immediately. One scenario where this is essential is where you're saving a parent record and one or more child records. When you save the parent record, you need to get the final ID from the database and put it back into your DataTable so that the foreign key values in the child row(s) can be updated before you save the child row(s). If you save the child row(s) without doing that then you'll violate the foreign key constraint in the database and an exception will be thrown.
Some data providers, e.g. SqlClient for SQL Server, support multiple SQL statements per command. In this case, you can simply add a SELECT statement after your INSERT statement and the new ID will get retrieved back into your DataTable with no extra code. Unfortunately, the Jet and ACE OLE DB providers don't support multiple SQL statements per command. As a result, you have to write some code explicitly retrieve the new ID when a record is inserted. Here's a quick code example of how you can do that with a typed DataSet:
''' <summary>
''' Handles the RowUpdated event of the parent adapter.
''' </summary>
''' <param name="sender">
''' The adapter that saved the row.
''' </param>
''' <param name="e">
''' The data for the event.
''' </param>
''' <remarks>
''' This event handler is used to retrieve an auto-generated ID from the database after a row is inserted and update the corresponding row in the local data set.
''' </remarks>
Private Sub parentAdapter_RowUpdated(sender As Object, e As OleDbRowUpdatedEventArgs)
'We are only interested in new records.
If e.StatementType = StatementType.Insert Then
'Get the last ID auto-generated by the database.
Dim lastAutoNumber = Me.parentAdapter.GetLastAutoNumber().Value
'Update the ID of the local row.
DirectCast(e.Row, ParentChildDataSet.ParentRow).ParentID = lastAutoNumber
End If
End Sub
In that case, GetLastAutoNumber is a query that I added to the table adapter in the DataSet designer. It is a scalar query that simply contains the following SQL:
SELECT ##IDENTITY
You can find the complete example here.