Member Avatar for Amiet_1

I have simple query.

Suppose if I am working on a project which contains one form (frmStudent) which is linked to table tblStudent.
Suppose if I release this this application. And after some time I created a new form in my project (frmTeacher)
And again for this form I have created new table (tblTeacher) in my database.

Now my question is, while i had this software delivered earlier (when it had only one form (frmStudent)) my client had inserted some records in database. After I update my application and again released my application, what will happen to these past entries? because I dont want to lose any past work of my client.

  • 3 Contributors
  • 2 Replies
  • 185 Views
  • 15 Hours Discussion Span
  • Latest Post Latest Post by Mr.M

Dani AI

Generated

described a common scenario: the app shipped with frmStudent/tblStudent, the client added records, and a later release adds frmTeacher/tblTeacher. Adding a new table to the same database is non‑destructive — existing rows in tblStudent remain intact — but data loss often happens during deployment when the deployed database file is overwritten by the installer or publish process.

Practical checklist to prevent data loss:

  • Treat schema changes as migrations, not file replacements. Create a SQL migration script that only creates the new table (or alters schema) and run it against the existing database.
  • Never ship a fresh copy of a data file that will overwrite the client’s live database. For local file DBs put the data file in a user/data folder (e.g. %ProgramData% or %APPDATA%) and have the installer create it only on first install.
  • For ClickOnce, mark the DB as a “data file” so the publish process preserves it across updates. For Visual Studio file properties, avoid “Copy always” for DB files; prefer “Do not copy” or manage copying in the installer.
  • Keep an explicit schema version (SchemaVersion table) and log applied migrations so updates run only once and can be audited.
  • Always take an automatic backup of the live DB before running migrations.

Example of a safe migration pattern (transactional, logged):

BEGIN TRANSACTION;
CREATE TABLE tblTeacher (
  TeacherID INT IDENTITY(1,1) PRIMARY KEY,
  FullName NVARCHAR(200) NOT NULL,
  Subject NVARCHAR(100) NULL
);
INSERT INTO SchemaVersion (Version, AppliedOn, Script) VALUES (2, GETDATE(), 'create_tblTeacher.sql');
COMMIT;

If records appear missing after an update, common causes include an overwritten DB file, an altered connection string pointing to a different DB copy, or file-permissions/redirected folders. ’s point about backward compatibility is crucial; ’s suggestion to test install/update cycles is exactly the right practice — test upgrades using real copies of the client database before shipping.

Recommended Answers

All 2 Replies

Member Avatar for Suzie999

It is your responsibility as developer to ensure your update is backward compatible and/or can import the old database to the new.

Member Avatar for Mr.M

The simple update will be to update the project its self. Meaning you will create your project and publish/release it, the if you feel of adding new features you need to update the already created project in that way when you publish its will create a new version folder and should an end user who is using an older version download and install the app will only change/add the new added features and the project will still be as it was with the new features now.

To test simply create a project then install it on your computer and update your project and install it again(installing the new version) you will see. I do this a lot before I release my projects. At least in VB.NET

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.