Theory
The bill needs to look like a bill
So far ShopKeeper reports each added item in a Label: one line, overwritten by the next. Mehta Uncle points at his old paper pad: item, quantity, amount, IN ROWS, with everything visible until the bill is done.
What the till needs is a table on screen. .NET splits that need into 2 halves with 2 names: something to HOLD rows of data, and something to SHOW them. Confusing the 2 halves is the classic Unit 3 mistake, so today we build both.
Theory
The register and the glass counter
The shop's register book holds the day's entries: ruled columns, one row per sale. It is the DATA, and it exists whether or not anyone looks.
The glass display counter SHOWS things: whatever you place inside becomes visible, arranged in its frame.
A DataSet is the register: tables of rows living in memory. A DataGrid is the glass: a control that displays whatever table you place in it. Register without glass: data nobody sees. Glass without register: an empty frame.
Theory
DataSet and DataGrid, formally
A DataSet is an in-memory container of DataTables (it can hold several, plus relations between them). Each DataTable has typed Columns and data Rows. Crucially it is disconnected: it needs no database, no connection, nothing but RAM. Today ShopKeeper fills it from code; in Unit 5 a DataAdapter will fill the very same structure from a real database.
A DataGrid (newer Visual Studio calls it DataGridView) is the display control: point its DataSource property at a table, and rows render as a grid automatically.
Practical
The bill: build the table, bind the grid
Public Class BillingForm
Dim bill As New DataTable("Bill")
Private Sub BillingForm_Load(sender As Object, e As EventArgs) _
Handles MyBase.Load
bill.Columns.Add("Item") ' String by default
bill.Columns.Add("Qty", GetType(Integer))
bill.Columns.Add("Amount", GetType(Decimal))
dgvBill.DataSource = bill ' the binding
End Sub
Private Sub btnAdd_Click(sender As Object, e As EventArgs) _
Handles btnAdd.Click
bill.Rows.Add("Soap", 2, 80D)
bill.Rows.Add("Tea", 1, 140D) ' grid updates by itself
Dim total As Decimal = 0
For Each r As DataRow In bill.Rows
total += CDec(r("Amount")) ' data, not display
Next
lblTotal.Text = "Total: " & total ' Total: 220
End Sub
End Class
Quiz
Where does a DataSet's data actually live while ShopKeeper runs?
- In memory (RAM), with no database or connection required
- In the DataGrid control that displays it
- In a temporary file Visual Studio creates on disk
- In the database; the DataSet is just a live window onto it
Show the answer
In memory (RAM), with no database or connection required
The DataSet is an in-memory, DISCONNECTED store: our listing builds and fills one with no database within miles. Option B inverts the register-and-glass split: the grid only displays; delete the grid and the data survives untouched. Option C invents plumbing that does not exist. Option D describes a connected model, and is exactly wrong in the word that matters: even when Unit 5 fills a DataSet FROM a database, the copy then lives independently in RAM, changes and all, until you push them back. That disconnected nature is the whole design.
Think first
One table, two glasses
Suppose a second grid on the Day Report tab also sets DataSource = bill. The Add button fires, 2 rows enter the table. Before tapping: what does each grid show, and what does that prove?
Show the answer
Both grids show both rows, instantly, because neither grid OWNS the data: each is a view of the same DataTable, and binding means the display follows the data wherever it changes. That is the proof of the split: data lives once (the register), displays are cheap windows onto it (as many glasses as you like). It also explains the golden habit in the listing: totals are computed from bill.Rows, never by reading grid cells, because grids are for eyes, tables are for logic.
Watch out
The confusions this topic is famous for
DataSet vs DataGrid: one holds, one shows. In an exam sentence: the DataSet is a disconnected in-memory data container; the DataGrid is the control that displays it.
DataSet vs DataTable: the DataSet is the file cabinet, DataTables are its drawers. Small programs often bind a lone DataTable directly, as we did.
Computing from the grid: reading cell text and re-parsing it invites format bugs; loop the DataTable's Rows instead.
Theory
This lesson is Unit 5 in rehearsal
Notice what today did NOT need: a database. The DataSet family was designed so screens work identically either way: today bill.Rows.Add fills it from code; in Unit 5, one DataAdapter.Fill(ds) will pour real saved bills into the same structure, and dgvBill will not know the difference. Learn the register-and-glass split now and ADO.NET becomes half-learnt. Next lesson: the invisible helpers in the component tray: Timer, ErrorProvider and friends.
Summary
Key takeaways
- DataSet = in-memory, disconnected container of DataTables; DataTable = typed Columns + Rows.
- DataGrid (DataGridView) = the display control; bind once with DataSource and rows appear as added.
- Build in code: Columns.Add(name, GetType(...)), Rows.Add(values...).
- Data and display are separate: many grids can watch one table.
- Compute from the DataTable's Rows, never from grid cells.
- Unit 5 fills the same DataSet from a real database via a DataAdapter: the screen code stays unchanged.
- Memory hook: DataSet is the register book, DataGrid is the glass counter.