Additional Articles


External Article

Clustering for Indexes

There is nothing spectacular about using indexes per say. However, on many occasions I have come across a variety of SQL coders that never consider validating that the index they think they are using is efficient or even being used at all. We can all put indexes on the columns that we think will be required to satisfy individual queries, but how do we know if they will ever be used. You see, if the underlying table data is constructed, contains, or is ordered in a particular way, our indexes may never be used. One of the factors around the use of an index is its clustering factor and this is what this article is about.

2004-12-23

3,412 reads

External Article

Cursors with SQL 2000 Part 1

This series of articles will examine the purposes, uses, and optimization of cursors in SQL 2000. SQL languages are designed so groups of records, or sets, can be manipulated easily and quickly. The speed at which groups of data can be altered, updated and deleted, demonstrates why working with sets is the preferred method. However, there are places where cursors are a better choice.

2004-12-20

2,572 reads

Technical Article

Optimizing Your SQL Code with SQL Server 2005

A common complaint of database administrators (DBAs) is that performance bottlenecks are not among those problems that one can fix "by just throwing hardware at it." Thus, database servers must provide tools and techniques to help administrators address this issue. On that aspect, SQL Server 2005 does not disappoint.

2004-12-16

2,373 reads

Technical Article

Auto Fix Orphaned Users

Add this procedure to the master database, it can then be executed from any DB to fix orphaned users (very useful when moving back to development). Using sp_msforeachdb with the proc allows you to resolve orphaned users in all databases in a single command: SP_MSFOREACHDB "USE ?; EXEC SP_AUTOFIX_USERS;"

You rated this post out of 5. Change rating

2004-12-15 (first published: )

2,886 reads

Technical Article

Easy Package Configuration

One of the age old problems in DTS is moving packages between your development, test and production environments. Typically a series of manual edits needs to be done to all the packages to make sure that all the connection objects are pointing to the correct physical servers. This is time consuming and gives rise to the possibility of human error, particularly if the solution incorporates many DTS packages. Many companies have provided their own custom solutions for managing this problem but these are still workarounds for a problem that is inherently DTS's.

2004-12-14

1,761 reads

Blogs

Rolling Back a Broken Release

By

We had an interesting discussion about deployments in databases and how you go forward...

A bespoke reporting solution doesn’t have to cost the earth

By

You could be tolerating limited reporting because there isn’t an off the shelf solution...

Presenting with Visual Studio Code

By

A while back I wrote a quick post on setting up key mappings in...

Read the latest Blogs

Forums

Remotely Engineer Fabric Lakehouse objects: The Fabric Modern Data Platform

By John Miner

Comments posted to this topic are about the item Remotely Engineer Fabric Lakehouse objects:...

Creating JSON III

By Steve Jones - SSC Editor

Comments posted to this topic are about the item Creating JSON III

Testing is Becoming More Important

By Steve Jones - SSC Editor

Comments posted to this topic are about the item Testing is Becoming More Important

Visit the forum

Question of the Day

Creating JSON III

In a SQL Server 2025 table, called Beer, I have this data:

BeerIDBeerName
1Becks
2Fat Tire
3Mac n Jacks
4Alaskan Amber
8Kirin
I run this code:
SELECT JSON_OBJECTAGG(
    BeerID: BeerName )
FROM beer;
What are the results?

See possible answers