Aim

To connect the Practical 14 admission form to a database: on Submit the Name, Email and Course are inserted into an SQLite table via sqlite3 using a parameterised INSERT query.

CO Mapping: CO1, CO2, CO3

Theory

SQLite is a serverless, zero-configuration relational database: the engine is a library inside your own process — no server to install, no credentials, no port, unlike client-server systems such as MySQL or PostgreSQL — and the whole database is one ordinary file, or, as here, ":memory:", held purely in RAM. Python ships the sqlite3 driver in its standard library.

Usage follows a fixed lifecycle: connect() opens (or creates) the database, cursor() gives the object that executes SQL, execute() runs one statement, commit() makes changes durable, close() releases the database. Commit is the step beginners forget — writes live in an implicit transaction, and an uncommitted INSERT is rolled back at close. Plain CREATE TABLE works here only because a :memory: database is born empty each run; file databases need the idempotent CREATE TABLE IF NOT EXISTS to survive reruns.

The INSERT is parameterised: VALUES (?, ?, ?) plus a tuple of values keeps data apart from the SQL text, so input can never become SQL syntax. Concatenating or f-stringing values in is the classic SQL injection hole — one apostrophe (O'Brien) breaks the query, and hostile input can rewrite it entirely.

The form is Practical 14's, unchanged; the new idea is where the write sits in event-driven code. submit() is the Button's callback: invoked by the event loop, it reads the entries with .get(), packs form_data and calls insert_admission(conn, form_data). The connection opens once at startup and is passed into the GUI, so every submission reuses it.

Dataset

No input dataset applies — the form stores data; exactly one row is inserted per run:

Procedure

1. init_db() connects to ":memory:" and creates the admissions table (id INTEGER PRIMARY KEY AUTOINCREMENT plus three TEXT NOT NULL columns), commits and returns conn.
2. insert_admission(conn, data) runs the parameterised INSERT with the tuple (data["name"], data["email"], data["course"]), then conn.commit().
3. run_gui_with_db(conn) rebuilds the P14 form — name_entry, email_entry, course_entry plus a Submit button wired to command=submit.
4. submit() packs the .get() values into form_data, calls insert_admission(), prints "Inserted via GUI:" and closes the window.
5. root.after(800, autofill_and_submit) types "GUI Student" / "gui@student.com" / "BCA" and presses Submit automatically.
6. On a headless online compiler tkinter raises instead, and the top-level except inserts the sample dict ("CLI Student") as the fallback.
7. Either way, conn.execute("SELECT ...").fetchall() (a connection-level shortcut) reads every row, the loop prints each tuple, and conn.close() discards the in-memory database.

Interpretation of Results

On a desktop the "Admission Form + DB" window fills itself after 0.8 s; the console shows Inserted via GUI: {'name': 'GUI Student', 'email': 'gui@student.com', 'course': 'BCA'}, then Rows in admissions table: and the single tuple (1, 'GUI Student', 'gui@student.com', 'BCA'). On a headless compiler the run reports GUI unavailable, inserted fallback data: with the CLI Student dict and a Detail: line, and the final row becomes (1, 'CLI Student', 'cli@student.com', 'BCA'). Either way the table holds exactly one row, and its leading 1 came from no INSERT — AUTOINCREMENT assigned it, which is why the column list names only name, email, course. Because the database is :memory:, conn.close() erases it — rerun and the table starts empty, id 1 again.

Common Mistakes

1. Forgetting conn.commit() — the row seems present (the open connection can SELECT it back) but is rolled back at close and vanishes.
2. Building SQL with an f-string, e.g. f"... VALUES ('{name}')" — one apostrophe breaks it and hostile input can inject SQL; use ? placeholders.
3. Using the connection after conn.close() — a late SELECT raises sqlite3.ProgrammingError; reconnecting to ":memory:" gives a new empty database.

🎯 Viva Questions

1. Why is SQLite called serverless? The engine is a library inside the Python process — no separate server or network; the database is one file or RAM (:memory:).
2. State the sqlite3 usage lifecycle. connect() → cursor() → execute() → commit() → close().
3. Why VALUES (?, ?, ?) instead of concatenation? Placeholders send values apart from the SQL text, preventing SQL injection and quoting errors.
4. Where does the printed id 1 come from? The INSERT omits id; INTEGER PRIMARY KEY AUTOINCREMENT assigns the next key.
5. How does the GUI trigger the write? The event loop runs the Submit callback submit(), which passes the .get() values to insert_admission().
6. How would the data persist across runs? Connect to a file like "admissions.db" and use CREATE TABLE IF NOT EXISTS so reruns do not fail.