locked
In a data driven application, how are changes to the database design handled for distribution to the end users? RRS feed

  • Question

  • Hi,

    VS2013, VB, SQL

    I don't know if this question requires an involved answer or an easy answer.  I assume the VS IDE already has an answer for this since it would seem to be an expected situation, and VS already tends to have solutions for many common scenarios.

    As my data based application changes over time it seems inevitable that, regardless of initial design diligence, I will have to add tables and/or change tables as new features are requested and added.  Is there a specific technique or process to accomplish this, or do we have to perform would I might call 'brute force' techniques to convert user data from the old database definition to the new database definition?

    I'm currently looking at using Click Once to deploy my application, in case that makes a difference.

    Thanks.

    Best Regards,

    Alan

    Monday, July 14, 2014 4:33 PM

Answers

  • Assuming the V2 (version 2) EF model has been updated, the V2 code tested, etc. and the V2 code is distributed...

    If I have, respectively, DB1 and DB2 for versions V1 and V2 of the code, then is the proper way to handle the move to the new DB2 design to use special code designed solely for transferring the entirety of DB1 data into DB2 so that V2 will be ready to operate?

    This is assuming that you have tested code agaist DB2,  and it's ready to go becuase you migrated the data from DB1 to DB2 in your testing.

    It's a two phased approach when deploying. 1) You have to have some standalone program that migrates the data from DB1 to DB2 before you can release the code to the client that works with DB2. It's up to you to accomplish this. And how you do this is really up to you. There is no standard game plan, and you have to figure out what to do to accomplish it.

    • Marked as answer by Alan Wheeler Monday, July 14, 2014 9:19 PM
    Monday, July 14, 2014 7:13 PM

All replies

  • It's like with anything else. If you make changes to the database or its tables, then the EF model has to be updated to refelct those changes,  and code in your application has to reflect those changes that must be implemeted and tested before deploying the solution to the client.

    Monday, July 14, 2014 5:42 PM
  • Hi,

    Assuming the V2 (version 2) EF model has been updated, the V2 code tested, etc. and the V2 code is distributed...

    If I have, respectively, DB1 and DB2 for versions V1 and V2 of the code, then is the proper way to handle the move to the new DB2 design to use special code designed solely for transferring the entirety of DB1 data into DB2 so that V2 will be ready to operate?

    I'm surely sorry for such a basic question, but I've never actually had to face this and wondered what the best practice is.

    Thanks.

    Best Regards,

    Alan

    Monday, July 14, 2014 6:55 PM
  • Assuming the V2 (version 2) EF model has been updated, the V2 code tested, etc. and the V2 code is distributed...

    If I have, respectively, DB1 and DB2 for versions V1 and V2 of the code, then is the proper way to handle the move to the new DB2 design to use special code designed solely for transferring the entirety of DB1 data into DB2 so that V2 will be ready to operate?

    This is assuming that you have tested code agaist DB2,  and it's ready to go becuase you migrated the data from DB1 to DB2 in your testing.

    It's a two phased approach when deploying. 1) You have to have some standalone program that migrates the data from DB1 to DB2 before you can release the code to the client that works with DB2. It's up to you to accomplish this. And how you do this is really up to you. There is no standard game plan, and you have to figure out what to do to accomplish it.

    • Marked as answer by Alan Wheeler Monday, July 14, 2014 9:19 PM
    Monday, July 14, 2014 7:13 PM