Saving Changes is Not Permitted?

In order to test drive the data modeling features of SS2008, I decided to use the engine for a real-world application.  I’m now attempting to use SQL Server to manage the Bateman household.  My first table in the design is a simple list of chores that we need to make sure get done around the house.

As I was putting together some of the details about how I would use this data, I decided to add a new column in order to specify the frequency (in days) which each chore should ideally be performed.  I was quite surprised to get the following error message when tying to add a nullable column to my existing table.

image

Saving changes is not permitted.  The changes you have made require the following tables to be dropped and re-created.  You have either made changes to a table that can’t be re-created or enabled the option Prevent saving changes that require the table to be re-created. 

Are you kidding me?  It wouldn’t let me add an “Allow Nulls” column?  That just seemed absurd so I did a bit more digging.

Apparently, this is now the default behavior for any of the following changes to a table:

  • Adding a new column to the middle of the table
  • Dropping a column
  • Changing column nullability
  • Changing the order of the columns
  • Changing the data type of a column

In order to prevent this default behavior, you simply need to uncheck a box in the table designer options using the Tools -> Options menu item

image

Expand the Designers section to display the Table and Database Designers options.

image

To change this behavior, just uncheck the “Prevent saving changes that require table re-creation” checkbox.

Although this is a bit frustrating, at least it is easy to fix and there is plenty of advice out there.  Here are some other people that found and posted this useful tidbit before me:

http://mirceacimpoi.spaces.live.com/blog/cns!98EC8584C8BBED54!849.trak

http://mtgcsharpguy.blogspot.com/2008/06/ms-sql-server-2008-new-features_13.html

http://www.danrigsby.com/blog/index.php/2008/09/26/sql-server-2008-error-saving-changes-is-not-permitted/

http://pragmaticworks.com/community/blogs/brianknight/archive/2008/06/04/sql-server-2008-designer-behavior-change-saving-changes-not-permitted.aspx

http://geekswithblogs.net/frankw/archive/2008/05/29/saving-table-changes-is-safer-in-sql-server-2008.aspx

Advertisements

Partial Classes and Inheritance

Since VS2005 created the ability to use partial classes, the feature has been available to developers across the .NET community.  This post is to provide a quick description of using inheritance and an example I found it to be particularly useful.

According to Microsoft, partial classes are most useful in these scenarios:

  • When working on large projects, spreading a class over separate files allows multiple programmers to work on it simultaneously.
  • When working with automatically generated source, code can be added to the class without having to recreate the source file. Visual Studio uses this approach when creating Windows Forms, Web Service wrapper code, and so on. You can create code that uses these classes without having to edit the file created by Visual Studio.

So by excluding bullet point #1 because I don’t agree with it (any source control system, even VSS, should facilitate this), we’re pretty much left with code generation.  The main reason partial classes were created is in order to allow part of a class to be regenerated via CodeGen and not have that blow away other code you have added since generation.

I recently found this helpful in working with an industry standard XML definition called WITSML.  We wanted to have C# data objects defined by the XML schema provided by the standard.  However, we also wanted to have these objects decorated with certain features that allowed the objects to fit into our overall data integration architecture.  In order to accomplish this, we simple created a matching partial class definition where we inherited from our base class and added any additional functions we wanted to have in the item.  I would provide some code samples, but this walks the line on some intellectual property issues since the concept belongs to my employer, so I’ll leave it up to your imagination  🙂

An interesting facet of the inheritance capability and the differences between C# and VB is discussed by Cory Smith on his blog.

The Mystique of CodeGen

For a few years now, there seems to be a lot of buzz about “CodeGen” as if it were some magical technology that is going to completely transform the software creation process. The boring lines of code that monkeys could probably write will now be magically created for us thanks to the quantum advances in technology.

The truth is, CodeGen is not only just a grossly overused term, it is also a commonly misrepresented one. So let’s take a minute and look at what the term really means:

  • Code: text that is compiled into machine instructions
  • Gen: “Generated” by something other than human fingers

OK, so that all still sounds pretty good, right? But what is it that drives the Gen part? I’ve been around computers for about 25 years, and the one thing that has remained the same is that they will do exactly what we tell them. Nothing more, nothing less. So we must be telling them how to generate this time-saving code, right?

This is where I think it is important to make a distinction between different types of CodeGen.

  • Object Relational Mapping (ORM)
  • Meta Data / Configuration
  • Environmental

Given the ambiguous nature of these terms, I feel it is justified to take a paragraph or two and describe why I see the CodeGen world split into these three categories

Object Relational Mapping (ORM)

ORM Diagram

ORM has gained quite a bit of notariaty due to the dramatic productivity increases that it can create. This technology is essentially taking your database object (tables, procedures, etc.) and mapping them into classes in code. There are even sub-categories of ORM depending on whether you have an existing database or plan to generate your database. However, for the purpose of this discussion, we’ll classify anything that directly maps code objects to relational database entities as ORM.

Meta Data / Configuration

A less written about and discussed method of generating code is to use configuration files, meta data, or other guidance to create the code. To me, the most interesting facet of this type of CodeGen is that most people use it and don’t even realize it. Have you ever used Visual Studio? If you have done any GUI development, you have probably seen the standard InitializeComponent(); method. The contents of this method are generated by Visual Studio based on the configuration in your .resx file. And is this resulting text anything other than bonafide code?

Another commonly used form of this type of CodeGen is to use custom configuration data to generate code classes. Whether this source data is stored in an XML file, database table, or any other type of data store the purpose is the same. Consistent images of code can be created from the configuration data before each build in order to blur the line between application code and configuration.

Environmental

I do feel that it is justified in noting one additional category of code generation techniques. Evironmental CodeGen refers to the process of gathering environmental data and using it to create code. In this context, environmental data can be server information, file properties, security information, or anything else that is dynamic and describes the state of a given environment. The distinction between environmental CodeGen inputs and configuration CodeGen inputs is that the designer or user may not know what the inputs will be for a given execution of the generation cycle.

My company uses an example of this type of code generation to generate HTML code that describes the versions of applications in all of the different technical environments. Although HTML walks the line of actually qualifying as code (since it is interpreted, not compiled) the concept holds true.

The last note about the environmental CodeGen approach reiterates an important distinction. A process that writes out a report should not be thought of as CodeGen. The results of the CodeGen operation should always be inputs into some compilation or other code utilization process. CodeGen is not simply scripting, but scripting can be CodeGen.

To summarize, I do believe that code generation is an amazing concept that everyone should be considering in today’s world of software development. It is important to spend time first understanding your problem, then knowing which approaches and tools will best suit your needs.