views:

169

answers:

4

What method do you use to get a compile time error when the database schema changes occur in an ASP.NET project?

For example, if you have a GridView bound to a DataSource, I can only get runtime errors when a schema change occurs, not a compile time error. Intellisense works fine on the code behind using datasets, LINQ, etc, but I cant seem to get a compile time error on an ASP.NET page when I change the schema.

Any advice?

A: 

One way I can think of easily achieving this behavior would be to databind to a dynamic DAL. There are some tools that can help do this DAL generation, I'd recommend taking a look at SubSonic.

Once you have something like SubSonic in place you can bind to the resulting business objects. These business objects will automatically change in the case of a schema change in the database and this will break your binding code which will result in a compile time error.

Update

Assaf's recommendation to use Unit Tests is also a good idea. It doesn't solve your stated problem but it is definitely something that should be in place and is a great tool for flagging these type of problems.

spoon16
The DAL will be regenerated if it's setup as a build task, otherwise this won't save him. You can still change the database schema without code generation. I agree it's definitely easier to track the modifications if you remember to re-generate the DAL classes.
Pawel Krakowiak
I'm not using it on any projects right now but I'm pretty sure SubSonic uses dynamic generation so that you do not have to manually update.
spoon16
+3  A: 

Create a unit test that verifies the correctness of you data access layer, and make sure it covers all your DB-related code. Not everything can be caught at compile time...

Assaf Lavie
+1 for common sense.
Kev
A: 

We use a modest system (xml to c++) to create schemas from an independent description, this system also creates names for tables and columns that we use inside the code, when there is a change in the schema the names change, as the names we originally used are not there anymore and the compiler will flag an error.

You could probably configure a lot of the DAO generation tools to do something similar.

Harald Scheirich
A: 

One solution would be to version your database and map an application build to a specific version (maybe in a properties file). In the entry point of your app, you can compare the expected version to the actual version and handle the error accordingly.

I'm not sure whats the equivalent in ASP.net of Migrations in Rails or dbdeploy in Java for versioning your database. But any DB versioning tool that makes schema changes incremental and versioned and tracks the version in a Version table will suit the purpose.

But if you want a compile time error while building your app, you might as well upgrade your schema to the latest version as part of your build process, avoiding the possibility of schema changes in the first place.

Sathish