Enterprise Manager Collision

Is there a setting for enterprise manager, to prevent two instances
from having the same stored procedure or any other object open and
overwritting one another?

Hi

No. As you could submit code through ISQL, OSQL, Query Analyzer, Enterprise
Manager, ADO etc.

Team co-ordination is required, usually only 1 person is allowed to make
changes to the development server after the other developers submit their
code to him.

Regards
--------------------------------
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland

IM: mike@epprecht.net

MVP Program: http://www.microsoft.com/mvp

Blog: http://www.msmvps.com/epprecht/

<jw56578@gmail.com> wrote in message
news:1114556996.995967.159010@z14g2000cwz.googlegroups.com...
> Is there a setting for enterprise manager, to prevent two instances
> from having the same stored procedure or any other object open and
> overwritting one another?
>

What you are hinting at is an underlying problem that every development
shop faces when more than one person needs to modify the same schema at
the same time.

I would ask the question "How do you manage changes for the non SQL
code in the system?" the answer to which *should* be the same in any
development team - "we use the source control system".  Using source
control is obvious for C++, Java, HTML etc. but not for SQL code as it
has some unique requirements, not least of which being that you cannot
simply drop and replace a target database with a brand new one that has
no data in it!

What you need is to be able to simply modify the schema creation
scripts under source control to regulate multiple developers modifying
the same schema.  This, for example, is the way you would work if you
were developing a brand new database that doesn't exist in production
yet.  To release the latest version of the database you simply build a
brand new one from the create scripts and deliver that.

But what if you already have a production database? You can't just
throw it away, you need to carefully modify it to bring it up to the
new schema level.

This is where a tool called DB Ghost (www.dbghost.com) comes in.  It
will build a brand new database from the scripts in source control,
which verifies that no syntax or dependency problems exist.  It then
uses that database as the source for a compare and upgrade of an
existing database i.e. production.  This keeps all data in place and
means that you will have a target schema that absolutely matches a
defined, labelled set of create scripts under source control.

This is called the "DB Ghost Process" and it is simply the best change
management solution I have ever seen as it is the only tool that works
with source code.

The more people use the product, the more they love it as it makes so
much sense.

No. Use a source control system such as Microsoft Source Safe for that.

--
David Portas
SQL Server MVP
--