Pro SQL Server 2005 Reporting Services

SQL Server Reporting Services 2005 is the latest version of the reporting technology from Mcft, providing the means to design, author, render, and deploy business reports to users, customers, and employees, via the web or the company intranet. The reporting engine is built in to the SQL Server 2005 database (and provided as a free add-on with SQL Server 2000) and the report manager is integrated with Visual Studio 2003, providing an effective and familiar environment for all SQL Server and .NET developers. The book was written in parallel with a migration project, moving some 200 professional healthcare reports from various reporting architectures to SQL Server Reporting Services, and so is steeped in the day-to-day challenges, discoveries, and successes involved in delivering a successful reporting solution with this technology. In this book, you will find step-by-step guides, best practices, and real code examples that cover all of the common Reporting Services tasks.

The book can be downloaded from here

Disclaimer: I assume no responsibility for any user downloading this e-book from my blog. This book is not hosted on my blog and I am just posting a link to another url where I found the book. Download the e-book at your own responsibility. I am just sharing the information I have. I suggest that don't use this e-book for commercial purpose and support the author by buying the print version.

Command-Line Utilities in SQL Server 2005

1) The sqlcmd utility allows you to enter Transact-SQL statements, system procedures, and script files at the command prompt. This utility uses OLE DB to execute Transact-SQL batches.
2) The sqlwb utility opens SQL Server Management Studio. If specified, sqlwb also establishes a connection to a server, and opens queries, scripts, files, projects, and solutions.
3) The profiler90 utility launches the SQL Server Profiler tool. The optional arguments listed later in this topic allow you to control how the application starts.
4) You can access Database Engine Tuning Advisor at the command prompt by using the dta.exe file, or through the application's graphical user interface (GUI). The command-line utility lets you incorporate Database Engine Tuning Advisor functionality into scripts and software programs. The dta utility also takes XML input. The Database Engine Tuning Advisor GUI makes it easy to view existing tuning sessions tuning recommendations.
5) You can use the Execute Package Utility dialog box to specify package run-time configurations and run packages on the local computer. You also can use this utility to generate command lines for use with the dtexec command prompt utility.
6) The dtutil command prompt utility is used to manage SQL Server 2005 Integration Services (SSIS) packages. The utility can copy, move, delete, or verify the existence of a package. These actions can be performed on any SSIS package that is stored in one of three locations: a Microsoft SQL Server database, the SSIS Package Store, and the file system. The package and its storage type are identified by the /SQL, /FILE, and /DTS options.
7) The tablediff utility is used to compare the data in two tables for non-convergence, and is particularly useful for troubleshooting non-convergence in a replication topology.

Siddharth Mehta
[MSc(I.T), MCP, MCAD, MCSD]

Using Profiler in SQL Server 2005 to measure performance

SQL Profiler along with performance counters statistics can be used to measure the performance.
The new Profiler tool that ships with SQL Server 2005 now provides the feature to compare the trace with the performance counters. The best way to experiment this example is to load your SQL Server instance with lot of activity, record the trace as well as the performance counter and compare the same in the SQL Server Profiler tool.

Download this tutorial which explains in details all the steps with relevant snapshots of all the steps.

Siddharth Mehta
[MSc (I.T.), MCP, MCAD, MCSD]

SQL Server 2000 Password Security

How does SQL Server store passwords?
SQL Server uses an undocumented function, pwdencrypt() to produce a hash of the user's password, which is stored in the sysxlogins table of the master database. This is probably a fairly common known fact. What has not been published yet are the details of the pwdencrypt() function. This paper will discuss the function in detail and show some weaknesses in the way SQL
Server stores the password hash. In fact, as we shall see, later on I should be saying, 'password hashes'.
What does an SQL password hash look like?
Using Query Analyzer, or the SQL tool of your choice, run the following query
select password from master.dbo.sysxlogins where name='sa'
You should get something that looks similar to the following returned.
0x01008D504D65431D6F8AA7AED333590D7DB186
3CBFC98186BFAE06EB6B327EFA5449E6F649BA954AFF4057056D9B
This is the hash of the 'sa' login's password on my machine.
What can we derive from pwdencrypt() about the hash?
Time
The query select pwdencrypt('foo')produces
0x0100544115053E881CA272490C324ECE22BF17
DAF2AB96B1DC9A7EAB644BD218969D09FFB97F5035CF7142521576
but several seconds later repeating the query select pwdencrypt('foo') produces 0x0100D741861463DFFF7B5282BF4E5925057249
C61A696ACB92F532819DC22ED6BE374591FAAF6C38A2EADAA57FDF
The two hashes are different and yet the input, ‘foo’, is the same. From this we can deduce that time must play an important part in the way password hashes are created and stored. The design reasons behind this will be such that if two people use the same password then their hashes will be different - thus disguising the fact that their passwords are the same.
Case
Run the query select pwdencrypt('AAAAAA')
which produces
0x01008444930543174C59CC918D34B6A12C9CC9E
F99C4769F819B43174C59CC918D34B6A12C9CC9EF99C4769F819B.
Now, we can note that there are probably two password hashes here. If you can't spot it immediately let me break it down
0x01008444930543174C59CC918D34B6A12C9CC9E
F99C4769F819B43174C59CC918D34B6A12C9CC9EF99C4769F819B
As can be seen, the last 40 characters are the same as the penultimate 40 characters. This suggests that passwords are stores twice. One of them is the normal case sensitive password and the other is the upper-cased version of the password. This is not good as any one attempting to crack SQL passwords now has an easier job. Rather than having to break a case sensitive password they need only go after the upper-cased version. This reduces the number of characters they need to attempt considerably.
Clear Salt
From what we know already, that changes in time will produce a change in the hash, there must be something about time that makes the password hashes different and this information must be readily available so when someone attempts to login a comparison can be performed against the hash derived from the password they supply and the hash stored in the database. In the breakdown of results from pwdencrypt() above the 84449305 portion is this piece of information.
This number is derived in the following fashion. The time () C function is called and used as a seed passed to the srand() function. srand() sets a start point to be used for producing a series of (pseudo)random numbers. Once srand is seeded the rand() function is called to produce a pseudo random number. This number is an integer; however SQL server converts this to a short and sets it aside. Lets call this number SN1. The rand() function is called again producing another pseudo random integer which, again, is converted into a short.
Let's call this number SN2. SN1 and SN2 are joined to produce an integer. SN1 becoming the most significant part and SN2 the least significant part : SN1:SN2 to produce a salt. This salt is then used to obscure the password.
Hashing the password
The user's password is converted to it's UNICODE version if not already in this form. The salt is then appended to the end. This is then passed to the crypt functions in advapi32.dll to produce a hash using the secure hashing algorithm or SHA. The password is then converted to its upper case form, the salt tacked onto the end and another SHA hash is produced.
0x0100 Constant Header84449305 Salt from two calls to rand()43174C59CC918D34B6A12C9CC9EF99C4769F819B Case Sensitive SHA Hash43174C59CC918D34B6A12C9CC9EF99C4769F819B Upper Case SHA Hash
The Authentication Process
When a user attempts to authenticate to SQL Server several things happen to do this. Firstly SQL Server examines the password entry for this user in the database and extracts the "salt" - 84449305 - in the example. This is then appended to the password the user supplies when attempting to log in and a SHA hash is produced. This hash is compared with the hash in the database and if they match the user is authenticated - and of course if the compare fails then the login attempt fails.
SQL Server Password Auditing
This is done in the same manner that SQL Server attempts to authenticate users. Of course, by far the best thing to do is, first off, is attempt to brute force the hash produced from the upper-cased version. Once this has been guessed then it is trivial to workout the case sensitive password.
Acknowledgements: The above articles was from a pdf document published by www.ngssoftware.com on 24th June, 2002.