Mike Schinkel asked me the other day how we do database deployments.

I started thinking and realized it breaks down into two scenarios:

1. Clean Build
2. Version Update Build

#1 is pretty easy to describe.  We script everything.  I am way to paranoid about temporary changes getting made in development that accidentally make their way into production to allow anyone to just replicate databases, use DTS jobs, etc.

All changes must be scripted, all scripts must be in source control, the database is build out of this source tree.  Typically the scripts are broken down like this:

• .sqt files which define the table structure
• .sqx files which define the indexes and primary keys
• .sqp files which define the stored procedures.  There is one file per sproc
• .sqd files which insert initial default data
  

One of my current clients has an implementation of this that as part of the nightly build process it goes through a node of the source tree and runs all .sqt files to put the base schema in place.  Followed by the sqx, sqp and sqd files.  The only problems come when the sqd files come into play and they attempt to insert default data in an order not allowed by constraints, etc.  Here we have a system whereby we can impose an order in which certain ones run.  Awkward at best but it works.

#2 is even more awkward.  In the case of #2 there is existing data in the database that needs to be preserved. As such we have .NB files that are used to make changes to an existing database.  These allow us to for example instead of doing a create table use alter table to add a column.  This is where it gets really hard.  Figuring out what to run and what not to run to preserve data already in the system.

I am suprised that I don't see any tools/nant steps to help automate this type of build.  It is clearly an essential part of the process.

Monday, March 15, 2004 9:56:46 AM (Pacific Standard Time, UTC-08:00)         Comments [0]  

Mike Sax mentions the ridiculous fees for setting up Passport to use for authentication into your site. We looked into this for a customer at one point and found it pretty much prohibitive.  It would have fit quite well for this customers target market but it just was not feasible for this company who had a few hundred customers/trading partners.  Sure helps to understand why you see so few passport enabled sites.

Tuesday, March 02, 2004 10:28:44 AM (Pacific Standard Time, UTC-08:00)         Comments [3]  

One step closer to my goal of being able to build our compact framework applications with NANT: http://blog.opennetcf.org/ncowburn/PermaLink.aspx?guid=6a7abb76-8d59-4dfa-b31c-0a2e1c1d781e

Monday, February 23, 2004 9:37:01 AM (Pacific Standard Time, UTC-08:00)         Comments [2]  

Check it out!  I am on .NET Rocks talking about some of the work we have been doing over the last couple of years.

Thursday, February 19, 2004 11:40:46 PM (Pacific Standard Time, UTC-08:00)         Comments [0]  

This is a great tip that I picked up from a random blog:  How to Make ActiveSync Default To Guest

Wednesday, February 11, 2004 10:56:26 AM (Pacific Standard Time, UTC-08:00)         Comments [0]  

An application I was working on recently required the ability to send a fax of a PDF. I have done fax integration in the past using Brooktrout hardware and FacSYS and other servers.  I must admit not only was I dreading doing the integration I worried that the client would balk at the startup cost. 

Then I came across Interfax. This is a faxing Web Service!  Reasonable at .07/page for nationwide faxing.

Check them out.

Thursday, January 22, 2004 2:35:04 PM (Pacific Standard Time, UTC-08:00)         Comments [0]  

It appears that I will be speaking at the Seattle DevDays 2004 on March 28, 2004.  Should be fun.

Tuesday, January 20, 2004 10:17:05 AM (Pacific Standard Time, UTC-08:00)         Comments [0]  

We have been using quite a number of the blocks that the PAG team is putting out and while on the whole we like them quite well they definitely have some rough edges.   Minimal documentation, messy code that looks like it was done in an incredible rush, etc...

Today however I ran across something that drives me nuts.  We are using the Asynchronous Invocation Block to push web service requests off our web servers.  To make async requests we are required to place a value in the web.config that the Request object provided by the block uses.  This is a connection string to the service database.

Did they create their own section handler and put it in there?  No.

Did they create at least a name that indicated this was a connection string for the Async block?  No.

They called it, TADA, “ConnectionString”!  Are these guys insane?  How many applications do you suppose already have a setting called ConnectionString that doesn't point at the service agent database that this block needs?

Have these guys written any applications before?  Did they integrate this into any of their applications?

Friday, January 16, 2004 10:28:32 AM (Pacific Standard Time, UTC-08:00)         Comments [0]  

Interesting article from www.theserverside.net on calculating load: Calculating Load.

Tuesday, January 13, 2004 8:15:10 AM (Pacific Standard Time, UTC-08:00)         Comments [0]  

Found a little gotcha today.  Didn't realize that the message of an event log entry was limited.  Looked at the docs and of course it mentions a 16K limit.  Odd thing is that I found the limit really appears to be ~32K not 16K.  I say approximately because I found that 32767 fails but 32700 works. Very, very odd.

Monday, January 12, 2004 10:56:04 AM (Pacific Standard Time, UTC-08:00)         Comments [0]