57.10. Best Practices

The following is a list of best practices we compiled through our work with Database Professional and which have worked for us on small and medium-sized projects:

  • Each developer works with his own local SQL database instance, one for development and another for testing. This is necessary to isolate uncommitted and untested changes and avoid affecting other developers working on the database at the same time. It is strictly necessary for managed-code debugging purposes, because starting a debugging session will cause all managed threads to stop. From the project properties for Database Projects you can specify the database to target for each Solution Configuration, but SQL-CLR projects can only target one database.

  • Each developer works with two databases, one for development and one for unit testing because different data will be used for each.

  • Use (local) or 127.0.0.1 for the hostname instead of, say, mikesComputer or 192.168.2.6, which would work only on one machine.

  • If you are using database instances, be sure all your developers have an instance with the same name.

  • All developers should have the same SQL Server version. Although SQL Server Express can be used for design-time validation and testing purposes, some features, like text Indexing, are not supported.

  • Clear the "Block incremental deployment if data loss might occur" checkbox in the project properties window for the Solution Configuration used for Test Databases. Because you will have a Data Generation ...

Get Professional Visual Studio® 2008 now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.