How can we help you today? How can we help you today?
Andras B
Well, this is a rather interesting problem. You set up a default value, and no longer allow nulls. But the table itself contains nulls [image] IMHO null data in such tables should be updated first to the new desired value, which may or may not be the new default value. It is difficult to decide automatically whether the nullability has been changed by mistake, or what the new value for the nullable column should be. While I would say that doing the data change automatically would corrupt the database, not everyone is as paranoid as I am, and I can see your point that such behaviour could be useful in certain cases. Therefore I've added this feature to SQL Compare. We will use the DRI default with ISNULL if a colum is changed from nullable to not nullable and a DRI default is already set up on the non nullable side, but not on the column that allows nulls. Also, in the first iteration we will not allow automatic reverting to the default value if the datatype has changed in any way. Assuming this feature will not bring unforseen problems in our tests it will be available in the next major release of SQL Compare (SQL Compare 7, scheduled for release in Q3). There will be a high priority warning accompanying such automatic data mangling. Regards, Andras / comments
Well, this is a rather interesting problem. You set up a default value, and no longer allow nulls. But the table itself contains nulls IMHO null data in such tables should be updated first to the ...
0 votes
Many thanks for all your comments. We have now added an option to add a use statement at the beginning of a script generated by SQL Compare 7. This option will be off by default. Regards, Andras / comments
Many thanks for all your comments. We have now added an option to add a use statement at the beginning of a script generated by SQL Compare 7. This option will be off by default. Regards, Andras
0 votes