Rolling Back Invalid Default Value for Column

Jan 2, 2011 at 6:31 PM

I just ran into a minor problem using the code generator. I had added a bit column to a table in the schema (wsgen) file, and mistakenly assigned it a default value of false. The code generator ran, the code compiled, but of course the upgrade script blew up when it tried to add the column to the table.

Setting the default value to a valid value (i.e., 0) by itself didn't solve the problem because of the way the upgrade scripts apparently run (i.e., in sequential order). The "fix" couldn't be reached because the earlier script with the incorrect value blew up first.

I solved the problem by manually editing the generated upgrade script to insert the correct value. Recompiling and running the installer then worked.

Ideally, it would be nice if these kind of changes could be handled, although off the top of my head I think that might be hard to do. Or, better yet, can value-checking logic be included in the default value property setter so that invalid values can't be entered in the schema file in the first place?

- Mark

p.s. BTW, do I have to worry about the modification to the generated upgrade script getting overwritten on the next generate? Will I have to keep making manual edit corrections forever?

Jan 2, 2011 at 6:46 PM

Some additional info on a related issue: it turns out I had also forgotten to define the new column as not nullable, so of course the table was originally modified to include NULL values in the new field.

Changing the field attribute in the schema file to not allow nulls also caused the upgrade script to blow up. But I think this kind of change (i.e., making a field non-nullable) could be handled by the code generator by first doing an UPDATE to set the value of any records with NULL values in the field being modified to whatever the specified default value is, and then doing the schema modification. That's effectively what I did by hand.

Coordinator
Jan 3, 2011 at 1:49 AM

The switching between NULL/NOT NULL was fixed a few days ago and will be in the next version. The true/false not mapping to 1/0 for bit fields is also fixed. Either syntax will work in the next version. Also there is some validation on default values now. Not everything but int types (int, tinyint, etc), string types, bit, real numbers (decimals, reals, etc), GUID and some others do have validation on them now. This should alleviate some of the issues. The next version will be coming soon.

Jan 3, 2011 at 2:31 AM

You guys are awesome!!!!