Interactive Student Project Checklist

PHP MySQL Database Import Checklist for XAMPP and phpMyAdmin

Importing an SQL file is not finished when phpMyAdmin displays a green success message. The database name must match the PHP configuration, the expected tables and data must exist, login and CRUD features must work, and the final database should be exported cleanly for submission. Use this checklist before, during, and after importing a PHP/MySQL student project database.

How to use this page: Work through the checklist in order. Your completed items are saved in this browser. Use the printable import record near the end to document the database name, SQL file, errors, fixes, login test, and final export for your report or project handover.

XAMPP phpMyAdmin SQL import Foreign keys Collation errors Database connection CRUD testing Final export

Database checklist progress 0 of 30 completed — 0%

Prepare the Project and SQL File

Do not begin by importing the first SQL file you find. Identify the real project database and preserve an untouched copy.

Extract the project completely Do not run or inspect the project from inside a ZIP or RAR archive. Confirm that all PHP, asset, configuration, and database folders were extracted.

Keep an untouched backup of the original SQL file Create a copy before replacing collations, removing statements, changing database names, or adding foreign-key wrappers.

Identify the main SQL dump Look for multiple CREATE TABLE statements. A tiny SQL file may contain only sample data, an update, or one table rather than the full database.

Search the SQL file for a database name Look for CREATE DATABASE and USE. Also inspect the PHP configuration for the database name expected by the application.

Find the database connection file Search for mysqli_connect, new mysqli, new PDO, DB_NAME, or localhost in files such as config.php, db.php, connection.php, or database.php.

Start Apache and MySQL in XAMPP Confirm that http://localhost/ and http://localhost/phpmyadmin/ open before blaming the SQL file.

A database import can succeed under one name while the PHP project still connects to another. Record the expected database name before importing anything.

Import the SQL File Correctly

Create a clean destination, select it first, and read the final import message instead of assuming that every statement succeeded.

Create a fresh database with the correct name A fresh database prevents old tables and partial imports from producing misleading “table already exists” or duplicate-key errors.

Select the destination database before clicking Import phpMyAdmin imports into the currently selected database unless the SQL dump explicitly changes the database itself.

Choose the correct SQL file Confirm the filename, size, and folder. Avoid accidentally importing a previous edited copy or an unrelated database export.

Keep the SQL format selected Do not switch the import format to CSV, XML, or another format when importing a normal .sql dump.

Wait for the import to finish Do not refresh, close the tab, restart MySQL, or import the file again while phpMyAdmin is still processing it.

Read the complete success or error message Copy the exact error number, line, table, column, collation, or constraint name. The exact message is more useful than “SQL did not work.”

Optional clean database creation

CREATE DATABASE student_project
  CHARACTER SET utf8mb4
  COLLATE utf8mb4_general_ci;

USE student_project;

Use the database name expected by the project. Do not paste this example unchanged when the application is configured for another name.

Diagnose Import Errors Without Damaging the Dump

Work from the first exact error. Later errors may be side effects of the first failed table or statement.

Retry in a fresh empty database If the first attempt partially created tables, delete the test database and repeat the import cleanly after saving the error message.

Check unsupported collation errors carefully Replace only the unsupported collation with a compatible one after keeping a backup. Do not globally change character-set names without understanding the difference.

Check the parent table before a foreign-key failure Confirm that the referenced table and referenced column exist, use compatible data types, and are indexed appropriately.

Use foreign-key checks only as a controlled import aid Disabling checks can help with dump order, but it does not repair missing parent rows, wrong data types, or invalid relationships. Re-enable checks and verify the data afterward.

Investigate duplicate table and duplicate key errors Determine whether the database contains an earlier partial import, the SQL dump repeats statements, or sample data contains duplicate unique values.

Check file-size and execution limits Large imports may exceed upload, post, memory, or execution limits. Use phpMyAdmin settings or the MySQL command line rather than splitting the file randomly.

Controlled foreign-key import wrapper

SET FOREIGN_KEY_CHECKS = 0;

-- Original CREATE TABLE and INSERT statements go here.

SET FOREIGN_KEY_CHECKS = 1;

This wrapper can help when valid tables appear in an inconvenient order. It should not be used to hide broken relationships. After importing, confirm that referenced records and constraints are valid.

Connect and Test the PHP Project

A successful import is only useful when the application can read and change the correct database.

Confirm that all expected tables exist Compare phpMyAdmin with the project modules, SQL file, or documentation. One missing table can break only part of the application.

Check whether important tables contain rows Inspect admin, users, roles, settings, categories, and other setup tables. A structure-only import may not contain required login or configuration data.

Update the PHP connection values Verify host, username, password, database name, and port. A typical local setup may use localhost and root, but use your actual configuration.

Open the project through localhost Use http://localhost/project-folder/. Do not double-click a PHP file and open it with a file:// address.

Test login and session flow Check the documented credentials or the relevant database table. Confirm that login, protected pages, logout, and role restrictions behave correctly.

Run a full CRUD test Create, view, update, and delete a test record. Confirm in phpMyAdmin that the correct table changed and no duplicate records were created.

A project database is functionally ready only when the application connects, reads data, writes data, preserves relationships, and supports its real user workflow.

Prepare the Final Database and Submission

Clean test data, export the final database, and document enough information for another person to run the project.

Remove accidental and sensitive test data Delete personal emails, real phone numbers, private tokens, copied customer data, and meaningless duplicate test records.

Keep useful demonstration data A completely empty database can make the project look unfinished. Keep safe sample records that demonstrate modules without exposing private information.

Export the final tested database Export from the database that the working application actually used. Give the file a clear name such as project_name_database.sql.

Test the exported SQL in another fresh database This proves the final file is portable and not dependent on tables left behind from earlier attempts.

Write setup and login instructions Record the database name, SQL filename, config-file path, localhost URL, demo credentials, and any required PHP extensions.

Prepare database documentation and viva notes List tables, primary keys, foreign keys, important relationships, CRUD modules, security limitations, and one improvement you made.

SQL Import Error Decision Table

Error or symptom	Most likely cause	Safe first action
Unknown collation	The dump was exported from a database version that supports a collation unavailable locally.	Back up the file, identify the unsupported collation, and replace it with a compatible collation appropriate for the project.
Table already exists	The database contains a previous or partial import.	Create a fresh empty database and retry once rather than deleting random statements.
Cannot add foreign key constraint	Missing parent table, incompatible column types, missing index, unsupported engine, or invalid existing data.	Inspect the referenced table and both column definitions before disabling constraints.
Duplicate entry for key	Repeated sample data, repeated import, or conflicting unique values.	Determine whether the database was already partially populated and inspect the exact key named in the error.
Unknown database	The dump or PHP project refers to a database that does not exist.	Create the expected database or deliberately update both the dump and PHP configuration to one consistent name.
Syntax error near a line	Corrupted export, unsupported syntax, missing delimiter, incomplete statement, or manual edit.	Compare the line with the untouched original and inspect the statement immediately before the reported location.
Import times out or stops	The file exceeds PHP upload or execution limits.	Check the file size and use an appropriate command-line import or carefully adjusted local limits.
Import succeeds but project shows no data	The project connects to another database, the dump contains only structure, or queries expect different table names.	Check the live connection values, selected database, table rows, and PHP query names.

Do not delete foreign keys, primary keys, unique indexes, or SQL statements only to make the import message turn green. That can leave a database that imports successfully but behaves incorrectly.

Import Shortcuts to Avoid

Editing the only copy

Always preserve the original SQL dump so you can compare changes and recover from a bad replacement.

Importing repeatedly into one database

Partial tables and duplicate data make later errors harder to understand. Use a fresh test database for each clean attempt.

Removing every foreign key

This may hide a schema problem and remove the relationships that keep project data consistent.

Changing every collation blindly

Replace only unsupported values and keep character-set behavior consistent across related tables and columns.

Assuming green means complete

Verify tables, rows, config values, login, CRUD, and a fresh re-import before calling the database finished.

Submitting real credentials

Remove private passwords, service keys, personal data, and production connection details from the project package.

Copyable Database Import Record

Complete this record while setting up the project. It can become the database-installation section of your README, report, or handover notes.

PHP/MySQL DATABASE IMPORT RECORD

Project title:
Project folder:
Local server:
PHP version:
Database server/version:

ORIGINAL FILES
Original SQL filename:
Original SQL backup location:
SQL file size:
Database config file:

DATABASE SETTINGS
Expected database name:
Imported database name:
Database host:
Database port:
Database username:
Password intentionally excluded from notes: Yes / No
Character set:
Collation:

IMPORT RESULT
Import date:
phpMyAdmin or command-line method:
Import completed: Yes / No
Number of tables expected:
Number of tables imported:
First exact error:
Error number:
Affected table or statement:
Fix applied:
Clean re-import completed: Yes / No

APPLICATION TEST
Project URL:
Database connection successful: Yes / No
Login tested: Yes / No
Create tested: Yes / No
Read/list tested: Yes / No
Update tested: Yes / No
Delete tested: Yes / No
File upload tested, if applicable: Yes / No
Role or permission test completed: Yes / No

FINAL PACKAGE
Sensitive test data removed: Yes / No
Safe demo data included: Yes / No
Final SQL filename:
Final SQL tested in a fresh database: Yes / No
Setup instructions included: Yes / No
Demo login instructions included: Yes / No
ER diagram/database explanation prepared: Yes / No
Viva questions prepared: Yes / No

Remaining issues:
1.
2.
3.

Technical References

Frequently Asked Questions

Should I create the database before importing the SQL file?

Usually yes. Create and select the destination database before opening the Import tab. Some dumps contain their own CREATE DATABASE and USE statements, so inspect the SQL file and project configuration first.

Why does the SQL file say table already exists?

The database probably contains tables from an earlier or partial import, or the dump repeats a table definition. Retry in a fresh empty database before editing the SQL file.

Can I disable foreign-key checks to fix an import?

You can temporarily disable them during a controlled import when valid tables are in the wrong order. Re-enable checks afterward. This does not fix missing referenced tables, mismatched columns, or invalid relationship data.

Why did the import succeed but the PHP project still fails?

The PHP connection may use another database name, username, password, host, or port. The dump may also be missing required data, or only some project modules may match the imported schema.

How do I know the database is fully working?

Confirm the expected tables and rows, connect from PHP, test login, and complete create, read, update, and delete operations. Then export the final database and import it into another fresh database.

Should the final SQL file include test data?

Include safe demonstration data when it helps reviewers understand the system, but remove personal information, real credentials, duplicate test records, private tokens, and unrelated data.

Can I submit only the SQL file?

A complete PHP/MySQL project normally also needs the source-code folder, setup instructions, database configuration guidance, screenshots, documentation, and any demo login information required by the evaluator.

What should I do with database passwords in the submission?

Do not include real production or personal database credentials. Use documented local development values or placeholders and explain where the reviewer should enter their own settings.

Final Check

A reliable database workflow has three successful results: the SQL dump imports cleanly into a fresh database, the PHP application performs its real workflows against that database, and the final exported SQL can be imported again by another person. Completing all three is much stronger than stopping at a green phpMyAdmin message.