locked
Adding Columns to Existing Tables and Displaying Them Without Recompiling. RRS feed

  • Question

  • User-1891342264 posted

    I'm currently trying to evaluate whether ASP.NET Dynamic Data is the appropriate technology to use for a project I am working on.

    One of the requirements of this project is that displaying new columns which are added to existing tables (and maybe adding new tables) should be possible without recompiling (ie - automatically discovering it or through changing a configuration file). For example, when I deploy this system on a customer site, they might want to add a column to a table and track some additional information. They do not want to open VS.NET 2008 and have to recompile. With ASP.NET Dynamic Data, it seems that if I add a column to an existing table, I will have to update the data model and recompile.

    Is there a way to add columns to existing tables and have them show up on the ASP.NET site without recompiling?

    Perhaps it might be acceptable to have a tool, which can refresh the data model by reading the database schema, and recompile it. Does such a tool exist?

    Thursday, December 11, 2008 5:50 AM

Answers

  • User-1005219520 posted

    You probably have no control over this, but routine DB schema changes are almost always due to poor design. L2S uses SqlMetal.exe to generate the model.  EF uses EdmGen.exe to Generate Object Model Files. You don't need to recompile anything on IIS if you deploy a web site (but you do if you go the web application route). This is very easy to automate if you don't change the generated model. I know one customer who makes many changes to the model and still has an automated process to update the DB schema changes to the model. (He uses sed type scripts to reapply his model customizations). The EF team is working on a way to modify the model outside of the wizard generated files so you can regenerate the model and retain your customizations - but until that is released model changes need to be reapplied.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, December 11, 2008 12:41 PM

All replies

  • User660823006 posted

    There are tools out there that will diff your data model against the actual database (see http://www.huagati.com/dbmltools/). You could then drop it into the bin directory and the application would restart showing the new tables. But I think it would be a manual process.

    Thursday, December 11, 2008 12:27 PM
  • User-330204900 posted

    In Dynamic Data you have to compose the model Linq to SQL is a pretty static model (although it can be rebuilt by adding an removing table and using SQLmetal command line utility) Entity Framework is a bit more flexible as you can do a refresh on the DB to reflect changes there but again it is at design time.

    So this may not be what you want you may want to have a look at the Dynamic Data Futures Preview 4.0 on Codeplex here  ASP.NET Dynamic Data 4.0 Preview 1.

    Hope this helps [:D]

    Thursday, December 11, 2008 12:41 PM
  • User-1005219520 posted

    You probably have no control over this, but routine DB schema changes are almost always due to poor design. L2S uses SqlMetal.exe to generate the model.  EF uses EdmGen.exe to Generate Object Model Files. You don't need to recompile anything on IIS if you deploy a web site (but you do if you go the web application route). This is very easy to automate if you don't change the generated model. I know one customer who makes many changes to the model and still has an automated process to update the DB schema changes to the model. (He uses sed type scripts to reapply his model customizations). The EF team is working on a way to modify the model outside of the wizard generated files so you can regenerate the model and retain your customizations - but until that is released model changes need to be reapplied.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, December 11, 2008 12:41 PM
  • User-1891342264 posted

    I'm developing a system where part of the requirements are the ability to extend the database model, but make little or no changes to the code to display the new tables. I think these tools are sufficient to support what I need.

    Thanks a lot for everyone's input!

    Friday, December 12, 2008 3:40 AM