Theory
The bills must survive the night
Everything ShopKeeper has built so far lives in RAM: close the app, and the day's bills evaporate. Mehta Uncle's register book laughs at your DataSet.
Unit 5 fixes this with a real database: ShopDB, with a Bills table, exactly the kind of thing you built in BCA205.
But before writing a line of database CODE, a professional looks at the database: what tables exist? what columns? is the server even reachable? Visual Studio has built-in tools for exactly that reconnaissance.
Theory
The tools, formally
Three visual database tools matter for this paper:
- Server Explorer: the IDE's window onto databases: add connections, expand tables, view and edit rows, create tables, all without leaving Visual Studio
- Query Designer: build a SQL query by ticking columns and joining tables visually, run it, and read the generated SQL (good BCA205 revision)
- Data Sources window: drag a table onto a form and Visual Studio generates a bound grid automatically
They explore and configure; the automation still belongs to code.
Follow along
Connecting to ShopDB, click by click
- View menu, Server Explorer The panel usually docks on the left, next to the Toolbox.
- Right-click Data Connections, Add Connection Choose the data source: Microsoft SQL Server for a server database, or a Microsoft Access database file (.mdb/.accdb) for a file-based one.
- Fill in server and database (or browse to the file) For a local SQL Server: server name . (a dot) and database ShopDB.
- Press Test Connection Verifies reachability and permissions BEFORE you depend on it. Fix problems here, not in code.
- Expand the new connection Tables, then Bills: right-click, Show Table Data, and the rows appear editable in the IDE.
Theory
The dialog's real output: a connection string
Everything you typed in that Add Connection dialog compiles down to one line of text, the connection string:
Data Source=.;Initial Catalog=ShopDB;Integrated Security=True
Data Source names the server (a dot means this machine), Initial Catalog the database, Integrated Security logs in as the Windows user. Select the connection in Server Explorer and its Properties pane shows the string, ready to copy.
Keep it: next lesson's ADO.NET objects demand exactly this string as their first ingredient.
Quiz
What does the Test Connection button in the Add Connection dialog actually verify?
- That your SQL queries are free of syntax errors
- That the server and database are reachable with the given credentials, right now
- That the Bills table contains valid data
- That ADO.NET is installed on the customer's machine
Show the answer
That the server and database are reachable with the given credentials, right now
Test Connection performs one live handshake: can this machine, with these credentials, open this database at this moment? Reachability and login, nothing more. It reads no tables (option C) and knows nothing of the queries you will write later (option A): SQL mistakes still await you in code. Option D confuses the target machine with your own; ADO.NET ships with .NET anyway. The habit it builds is the point: prove the pipe works before pumping anything through it.
Think first
Tools or code? Rule on 3 jobs
Three jobs: (1) check whether yesterday's bills actually reached the Bills table, (2) save every new bill automatically as the cashier clicks Print, (3) try out a SUM query before trusting it. Assign visual tools or ADO.NET code to each, before tapping.
Show the answer
(1) Tools: Server Explorer, Show Table Data: a 10-second eyeball, no code deserved. (3) Tools: Query Designer runs the SUM interactively until it is right; THEN the proven SQL moves into code. (2) Code: only ADO.NET running inside ShopKeeper can act automatically at click-time; no IDE window ships with the till. The division to remember: tools for exploring, verifying and prototyping; code for anything the APPLICATION must do by itself, which is next lesson's whole business.
Watch out
Where the demo dies
Editing live data casually: Show Table Data edits the REAL database as you type: fine in ShopDB on your laptop, catastrophic in a production shop's data. Know which connection you are touching.
Hand-typing connection strings from memory: one misspelled Catalog and nothing connects; copy from the tested connection's Properties pane instead.
Assuming the tools travel with the app: they are Visual Studio features; the deployed ShopKeeper has only your code and the string.
Theory
Reconnaissance done
You can now see the battlefield: ShopDB reachable (tested), Bills table browsable, a working connection string copied and waiting. What remains is teaching SHOPKEEPER to do at run time what you just did by hand: open the connection, send BCA205's SQL, carry results home. That machinery, 5 objects with exactly one job each, is the ADO.NET object model: next lesson, and the last new architecture of this subject.
Summary
Key takeaways
- Server Explorer connects to and browses databases inside Visual Studio: tables, data, even table creation.
- Add Connection: choose provider (SQL Server or Access file), name server and database, then ALWAYS Test Connection.
- Query Designer builds and test-runs SQL visually; Data Sources drags tables into bound grids.
- The dialog's true product is the connection string: Data Source, Initial Catalog, security settings.
- Tools explore, verify and prototype; ADO.NET code automates: both, in that order.
- Show Table Data edits the real database: respect the connection you are on.
- Memory hook: test the pipe before you pump.