Showing posts with label SQLServer. Show all posts
Showing posts with label SQLServer. Show all posts

Wednesday, February 29, 2012

Connection timeouts in a mirrored SQLServer

Recently, one of my teams was facing a connection timeout issue when we tried to implement 'parallelism' in a data-driven application.
A colleague of my mine pointed out that there was a bug in ADO.NET (with a mirrored SQL Server) that could result in this wierd behavior. More details available at this link.

Quick resolution is to try increasing the connection timeout and allocate a greater no of connections at start-up in the pool.

Wednesday, April 21, 2010

Referential Integrity across databases in SQL Server

Having worked on Oracle databases for a long time, I was quite comfortable with the idea of maintaining RI across different schemas in same database. For e.g. Ur database may have a schema containing master tables and your transaction schema references the lookup data in the master tables.
But to my suprise, prior to SQLServer 2005, it was not possible to have separate schemas in SQL Server. This meant that there was no easy way to maintain RI across databases in SQLServer. The only options were using messy triggers or a CHECK constraint with a UDF (user defined function)

Maintaining RI across databases is still not possible in SQLServer, but SQLServer 2005/2008 have added the concept of schemas in databases; i.e. it is possible to have multiple schemas in each database and each schema offers the same logical separation that a separate database would. We can also configure the schema to be located on a separate filegroup or a separate disk, thus maximizing performance. In SQLServer 2005/2008, it is possible to have RI constraints across schemas. I think this is the best design approach to take. If it is not possible to have your master data in the same database, then the second best approach is to use replication to get the master data into your database.