Tech Off - ALTER Datatype of Column - SQL

vulcandeathgrip — Fri, 04 Jan 2008 14:12:56 GMT

SQL Server might complain if reducing the size of the field would delete data already in the column. Is there some reason why you can't just create a new column, copy & convert the field data with an UPDATE statement, then remove the old column?

It sounds like an odd request; nvarchar is a flexible data type that also supports nulls. Maybe you need to put on your "change management" hat

Tech Off - Connection String for Typed Datasets

vulcandeathgrip — Fri, 04 Jan 2008 00:21:51 GMT

There's been a lot of talk about this subject going all the way back to before the initial release of .NET 2.0, but no one seems to be able to come up with a definitive solution. It seems that application configuration in .NET is very confusing, especially when it comes to deployment.

To my way of thinking, you ought to be able to simply include a different app.config file in your deployment package (most commonly, to use a different connection string when deployed), and have those settings picked up at runtime on the target. Otherwise, what the heck is app.config good for?

Some people have suggested placing the settings in web.config instead, but contrary to what many believe, IF your DAL is in a class library project, you CANNOT access the web.config file from the TableAdapter wizard nor the property setting of a TableAdapter (I'm trying it even as I write this just to be sure... nope, can't.)

Certainly, during the build process, any changes you make in app.config, it being one of your source files, ought to be compiled into the project settings (the settings.settings file and/or the x.exe.config file). You should not have to reopen Visual Studio, open the properties form and answer a pop-up message box to make this happen.

I agree with Kennon McCaa's statement in his blog posting of last July (http://kmccaa.blogspot.com/2007/07/how-to-move-typed-dataset-to-its-own_11.html) that this is a pretty big oversight, either in the architecture itself, or at the very least in the documentation.

My conclusion: It's probably true that Typed Data Sets should not be used in production except in very simple applications and in situations where the developer also has control over the deployment target environment.

I'm just starting to use the newer tools now, and am hoping that this situation is addressed in VS2008 some way or another, either by improving application configuration, or by providing better direction to developers in the form of documentation that is clearer, consistent and -- just as important -- easy to find.

+++

I should have mentioned: If you do use Typed Data Sets, don't put the Data Access Layer in a separate (class library) project. Instead, just add it to your Web project. If you do it that way, your table adapter WILL be able to read the web.config file, will do so at runtime, and you won't run into the deployment problem.

This is the approach taken by Scott Mitchell in his excellent tutorial series on the ASP.NET community site. In one of the tutorials, Scott recommends placing the DAL in a separate project, even though the sample application is all in one project, for simplicity. Recommendation: check out the data tutorials, but do as he DOES, not as he SAYS

Channel 9 - Discussions by vulcandeathgrip

Tech Off - ALTER Datatype of Column - SQL

Tech Off - Connection String for Typed Datasets