Month: August 2007
Solving Suspect Database
— The following commands take database ‘foo’ offline and then on again:
ALTER DATABASE foo SET OFFLINE
ALTER DATABASE foo SET ONLINE
More Thinking about Validation
This is a series of posts that relate to Validation and the use of the Notification Pattern.
This guy is heading in the same direction that we have been using at my work. There are a few details that he has not yet dealt with:
There is more you can do in this manner than validation. You can apply defaults, calculations and more complex business logic. This is the start of a rules engine.
A key point that is lost in an attributes based approach is that only a single question may be asked.
In this case the question is “Is the system valid”? But is could equally be can I add an XYZ here?
Minor Namespace Feature
Namespaces in C# and packages in Java are a convenient method of keeping related classes together. If you want to use code in another package in java you need to import the classes. This means that two distinct namespaces are entirely unrelated.
I used to think that the C# namespaces worked in the same way. However it seems that namespaces form a hiearchy.
Namespace A.B.C automatically has access to Namespaces A and A.B
This is a minor detail but is not that clearly stated in the tutorials that you normally get. It is in the language guide but not as clearly stated as it could be.
Real World Applications : Deployment and Upgrading
When an application is initially being developed life is relatively simple for the developer. There is an application and there is a database. You can tear down the database and rebuild it with impunity.
Once it has been deployed life gets a little more complex. Databases require upgrade scripts. You need to know which version of an app is on each users machine.
Life gets a little more complex once you have multiple deployment stages. The simplest is the QA/Test database and the Production Database. In almost all cases you want to script changes to the test database and only run the finished scripts against the production server (having backed it up first). Personally I find it far easier to control a database if every seperate item is scripted in a one feature two script file basis: Create Constraint/Drop Constraint, Create Table/ Drop Table. This works great for databases that you control directly. This becomes hard when you don’t have control.
Recently I have been working on a workflow application (Team Track). It is relativley painless to make chnages in the test environment. The problem comes when you want to deploy those changes to production. The migration tools do not migrate all of the options – the poor developer has to recreate everything by hand. Server tools should be fully scriptable. Developers need to think of how to partition their applications to cope with more complex production deployment stages.
MS Analysis Server 2000 also suffers this problem – you need to manually copy the changes from one server to another. What were the developers doing when they left out scripting?
What I described is the simple case. Oftern there are more stages (QA, UAT, Staging, Pre-Live, Live).