>>
I'm trying to understand what you're trying to accomplish.  EDB won't be
offering concurrent table alterations with active users or sessions, so that
is basically off the table.  I was going to offer an alternative path as
soon as I understood what your requirements were.

I appreciate all of the comments.  The ability to modify a table structure concurrently
has been available in MS SQL for a long time.  We do live web databases across the
enterprise.  I am not in the practice of "pulling the rug" by changing table structures
while users are working etc, and it is quite easy to "turn off" the application while the
structure is changed.  It is simply just much easier to do this sort of thing using the
higher end database products.

John

John,

<< I appreciate all of the comments.  The ability to modify a table
structure concurrently has been available in MS SQL for a long time. >.

This sounded a bit too easy, so I did some looking into how SQL Server 2005
handles ALTER TABLE in terms of locking:

http://blogs.msdn.com/sqlcat/archive/2006/03/01/541550.aspx

As you can see, your general statement that it can modify the table
structure concurrently is correct, however it can only do so in a
non-blocking manner on only the most basic of operations that involve adding
columns and/or constraints in a way that doesn't change the existing data in
any way or force it to be revalidated.  IOW, there are going to be non-basic
table alterations that will block access to the table rows for long periods
of time if there are a lot of rows in the table.  We could do the same thing
with EDB, but it would be essentially the same thing as allowing the table
to stay open while we blocked out any reads or writes to the table.  IOW, it
wouldn't be particularly useful in most cases.

<< We do live web databases across the enterprise.  I am not in the practice
of "pulling the rug" by changing table structures while users are working
etc, and it is quite easy to "turn off" the application while the
structure is changed.  It is simply just much easier to do this sort of
thing using the higher end database products. >>

Perhaps for basic operations, yes.  However, there is no such thing as a
free lunch, and schema changes are usually very intrusive in terms of
resource locking and concurrency.  It's their very nature that makes them
this way.

--
Tim Young
Elevate Software
www.elevatesoft.com