Dewayne Mikkelson: SQL FAQ

DBCC Commands.

Sat, 22 Nov 2003 15:29:43 GMT

Hey have a look at the DBCC Commands

Faster than speeding light!

Fri, 31 Oct 2003 12:14:54 GMT

Source: http://weblogs.asp.net/ssadasivuni/

Want to achieve it ? (In SQL Query Analyzer)
I found every MS Employee (SQL guys) doing this...so I decided to learn it thier way :)

Activity	Shortcut
Bookmarks: Clear all bookmarks.	CTRL-SHIFT-F2
Bookmarks: Insert or remove a bookmark (toggle).	CTRL+F2
Bookmarks: Move to next bookmark.	F2
Bookmarks: Move to previous bookmark.	SHIFT+F2
Cancel a query.	ALT+BREAK
Connections: Connect.	CTRL+O
Connections: Disconnect.	CTRL+F4
Connections: Disconnect and close child window.	CTRL+F4
Database object information.	ALT+F1
Editing: Clear the active Editor pane.	CTRL+SHIFT+DEL
Editing: Comment out code.	CTRL+SHIFT+C
Editing: Copy. You can also use CTRL+INSERT.	CTRL+C
Editing: Cut. You can also use SHIFT+DEL.	CTRL+X
Editing: Decrease indent.	SHIFT+TAB
Editing: Delete through the end of a line in the Editor pane.	CTRL+DEL
Editing: Find.	CTRL+F
Editing: Go to a line number.	CTRL+G
Editing: Increase indent.	TAB
Editing: Make selection lowercase.	CTRL+SHIFT+L
Editing: Make selection uppercase.	CTRL+SHIFT+U
Editing: Paste. You can also use SHIFT+INSERT.	CTRL+V
Editing: Remove comments.	CTRL+SHIFT+R
Editing: Repeat last search or find next.	F3
Editing: Replace.	CTRL+H
Editing: Select all.	CTRL+A
Editing: Undo.	CTRL+Z
Execute a query. You can also use CTRL+E (for backward compatibility).	F5
Help for SQL Query Analyzer.	F1
Help for the selected Transact-SQL statement.	SHIFT+F1
Navigation: Switch between query and result panes.	F6
Navigation: Switch panes.	Shift+F6
Navigation: Window Selector.	CTRL+W
New Query window.	CTRL+N
Object Browser (show/hide).	F8
Object Search.	F4
Parse the query and check syntax.	CTRL+F5
Print.	CTRL+P
Results: Display results in grid format.	CTRL+D
Results: Display results in text format.	CTRL+T
Results: Move the splitter.	CTRL+B
Results: Save results to file.	CTRL+SHIFT+F
Results: Show Results pane (toggle).	CTRL+R
Save.	CTRL+S
Templates: Insert a template.	CTRL+SHIFT+INSERT
Templates: Replace template parameters.	CTRL+SHIFT+M
Tuning: Display estimated execution plan.	CTRL+L
Tuning: Display execution plan (toggle ON/OFF).	CTRL+K
Tuning: Index Tuning Wizard.	CTRL+I
Tuning: Show client statistics	CTRL+SHIFT+S
Tuning: Show server trace.	CTRL+SHIFT+T
Use database.	CTRL+U

[WebLogs @ ASP.NET]

Version 3 of SQL Server CE

Tue, 28 Oct 2003 22:00:39 GMT

New SQL CE stuff from PDC.

Version 3 of SQL Server CE will eliminate a lot of the problems that developers have neen dealing with, working with SQL Server 2. One of my greatest shocks when I first userd SQL Server CE was that if I left SQLCE Query up and connected to my database, when I ran my applicaiton that accessed it, I got a sharing exception. No more with SQL Server CE 3 (Net yet available, due for Yukon B2 timeframe).

Also, the new Workbench allows you to run SQL CE queries on your handheld from the desktop, and more important, can show the execution plan, and accept hints (implemented slightly differently than on Sql Server).

The bad news? Still no stored procedures, so it is still likely the database layer will have to be seriously refactored for Pocket PC use.

[WebLogs @ ASP.NET]

Collations & Primary Keys.

Sat, 25 Oct 2003 23:30:41 GMT

Source: WebLogs @ SqlJunkies.com

The COLLATION of a column defines (among other things) the case sensitivity of search arguments when qualifying rows to be returned from SELECT statements as defined in WHERE clauses. But another important consideration is that a column's collation can also affect the behaviour of a unique / primary key if one exists on a column with collate defined.

For example, the following script demonstrates that uniqueness of rows inserted into a key depends on the collation of the key column. Note carefully that the collation is either “_CS_” or “_CI_” - denoting case sensitive or case insensitive. Depending on how ths collation is set, the “duplicate” rows are either allowed or rejected by SQL Server.

set nocount on
go
create table t1 (
col1 varchar (10) collate Latin1_General_CS_AS not null primary key)
create table t2 (
col2 varchar (10) collate Latin1_General_CI_AS not null primary key)
go
insert into t1 (col1) values ('a')
go
insert into t1 (col1) values ('A')
go
insert into t2 (col2) values ('a')
go
insert into t2 (col2) values ('A')
go
select * from t1
select * from t2
go
drop table t1
drop table t2
go

Output from this script is:

Server: Msg 2627, Level 14, State 1, Line 1
Violation of PRIMARY KEY constraint 'PK__t2__2042BE37'. Cannot insert duplicate key in object 't2'.
The statement has been terminated.
col1
----------
a
A

col2
----------
a

The case in point here is simply that the case sensitivity in any given collation does not simply affect row qualification for select statements. It also affects the uniqueness of rows permitted by the column's key (if one exists). In short, take care to get the case sensitivity right (usually case insensitive would be expected) when setting collations on primary keys!

Greg Linwood
www.bainlinwood.com

[WebLogs @ SqlJunkies.com]

Removing Duplicates.

Thu, 23 Oct 2003 14:41:12 GMT

Source: Geekswithblogs.net Main Feed

Simple way to Remove Duplicate Rows from an Existing Table in SQL

SELECT DISTINCT *
INTO duplicate_table
FROM original_table
GROUP BY key_value
HAVING COUNT(key_value) > 1

DELETE original_table
WHERE key_value
IN (SELECT key_value
FROM duplicate_table)

INSERT original_table
SELECT *
FROM duplicate_table

DROP TABLE duplicate_table
[Geekswithblogs.net Main Feed]

The Case for Case

Wed, 15 Oct 2003 00:11:53 GMT

Source: Stephen Forte's WebBlog

Ok I have gotten a lot of press because I love the Rozenshtein Method for creating cross tab queries. I have even traveled the world and spoke about it all summer at TechEds around the world.

I have gotten flack, especially from annoying Australians, about how “complex” the Rozenshtein Method is. So today I found myself writing a crosstab and used the Case Method.

It was an ad-hoc query that I have to run a few times over the next few weeks. It never has to run in another database like Access or Oracle. It was needed to be quick and dirty. I decided NOT to use the Boolean aggregates and use a Case statement. The basic structure of a case statement is as follows:

CASE FieldName WHEN ValueYouAreChecking THEN TrueExpression ELSE FalseExpression END

Pretty easy no? Here is a sample:

SELECT tlkpWeekEnding.WeekEnding_DT as Weekending, DiceCat.DiceCat_NM as 'Job Category', Sum(tblData.TotalListings) AS 'Total Listings', SUM(CASE Service_ID WHEN 1 THEN TotalListings ELSE 0 END) AS HotJobsTotal,

SUM(CASE Service_ID WHEN 2 THEN TotalListings ELSE 0 END) AS MonsterTotal,

SUM(CASE Service_ID WHEN 3 THEN TotalListings ELSE 0 END) AS CareerBuilderTotal

FROM DiceCat INNER JOIN ((tlkpWeekEnding INNER JOIN (trelServiceURL INNER JOIN tblData ON trelServiceURL.URL_ID = tblData.URL_ID) ON tlkpWeekEnding.WeekEnding_ID = tblData.WeekEnding_ID) INNER JOIN DiceCatDetail ON trelServiceURL.JobCategory_ID = DiceCatDetail.CorzenJobCatID) ON DiceCat.DiceCat_ID = DiceCatDetail.DiceCat_ID

WHERE tlkpWeekEnding.WeekEnding_ID=75

GROUP BY tlkpWeekEnding.WeekEnding_DT, DiceCat.DiceCat_NM

Order by DiceCat.DiceCat_NM

Here are the results, we move rows to columns:

View1
Weekending	Job Category	Total Listings	HotJobsTotal	MonsterTotal	CareerBuilderTotal
10/12/2003	Accounting/Auditing/Finance	37226	10021	9694	17511
10/12/2003	Banking/Mortgage	10657	2026	2886	5745
10/12/2003	Biotech/Pharmaceutical	7569	2290	2644	2635
10/12/2003	Engineering	20549	3513	5800	11236
10/12/2003	Healthcare	44080	4415	8028	31637
10/12/2003	Information Technology	34309	10637	8924	14748
10/12/2003	Insurance	8364	1900	2718	3746
10/12/2003	Legal	7962	1976	2498	3488
10/12/2003	Science	4636	0	1074	3562
10/12/2003	Telecommunications	3650	1005	1137	1508

So if this is so easy why oh why do I insist on using the Rozenshtein Method? Well, I don’t insist on using it all the time. I like it because it is super fast and make sense to me (I was into Math as a kid, sorry). I think that you should know both and use the one that you think is most effective for the job at hand.

Happy Crosstabbing! [Stephen Forte's WebBlog]

Debugging DTS Packages

Sun, 05 Oct 2003 15:29:49 GMT

You haven’t really experienced sheer hell until you have to debug a DTS package. SQL Server development is something completely different from the traditional 4GL languages like VB and C#, you have to think in rows and columns and joins. A lot of 4GL programmers are forced or simply want to get into writing T/SQL Stored Procedures and realize that it is a whole new ballgame. But one that is easy to master if you put the time in. So a lot of beginning SQL Server programmers who came over from the 4GL side ask me often at conferences, “How do I debug a DTS package?” The answer is “You don’t.” (Oh we are all so spoiled by setting a breakpoint in Visual Studio.)

Microsoft has publicly announced some of the new DTS features of Yukon at TechEd in Barcelona and will announce more at the PDC in LA later this month, so I won’t go there and besides Yukon will ship sometime over the rainbow. So let’s start thinking about SQL Server 2000.

First off, proper design of your package will only make debugging much easier. Use only Stored Procedures (with or without parameters) and if you have to use SQL dynamically utilize Views. This is because the more dependencies on “real” database objects, the easier it will be to track down your problem. Avoid ActiveX Scripts as much as you can-consider an Extended Stored Procedure that calls a DLL wrote yourself (or call the DLL with a CreateObject in your script if you must).

For the actual debugging itself my advice to you is to take everything in steps. You can run each DTS package’s step individually just by right clicking on it in the designed and selecting “Execute Step” from the pop-up menu. That is the first part. Then you can deconstruct the step manually and run those pieces in Query Analyzer. (In theory you can debug your stored procedure in Visual Studio too.) From there it gets easier, small bits and pieces of your step may or may not be working, so start looking at your select statements in QA. Before you know it, you will be in DTS debugging heck instead of hell.

[Stephen Forte's WebBlog]

SQL Server Security: SQL Injection

Sun, 28 Sep 2003 18:30:12 GMT

Robert Hurlbut says:

This past week, I concluded my talk on Security Coding: Best Practices at my work site. This was a continuation of Part 1 that I started last week. In particular, I dealt with SQL Injection and issues with Encryption and Cryptography.

I spent a little more time on SQL Injection, because this is a very interesting security issue to me. Even though you think your data is safe behind a few layers (UI, middle-tier), if you are not careful in how you process your calls to your database using the input from the UI, an attacker can easily gain lots of information about and from your database, including retrieving sensitive data and the structure and names of your tables. An attacker can also drop tables and kill your database completely.

SQL Injection is especially possible when concatenated strings are used for SQL queries. For example, if an input form requests a user to enter his/her name and password, and those inputs are used in a query string to determine access:

sql = “select * from users where userId = '“ + userName + “' and password = '“ + password + “'“;

An attacker can use a single quote (') in the userName input field to stop the string. After that, an “ OR 1 = 1 --” could be appended. This sets up a logical condition that will always be true. Plus, the “--” comments out the rest of the SQL query. So, the above query would be sent to the database like this:

select * from users where userId = '' OR 1 = 1 -- ' and password = ''

This would effectively bring back all user information. Very bad.

The key is checking all user input (“Never, ever trust user input“). Check that numeric fields are numeric. Check that string fields have double “single quotes“ (i.e. use a replace function to change single quotes (') into double single quotes ('')). Use stored procedures for access to any data, and when using stored procedures, implement them using the ADO command object or SQLParameter collection and classes so that variables are strongly typed. Always design and code for security from the first day, and test, test, test.

I have put together a list of further resources I have found useful in learning about SQL Injection as well as how to protect against it.

Advanced SQL Injection

Whitepaper on SQL Injection

Protecting Yourself from SQL Injection Attacks

SQL Injection FAQ

[WebLogs @ SqlJunkies.com]

Sun, 10 Aug 2003 22:11:19 GMT

Source: Nick's Blog says:

Marc just sent me a query showing how to query for a "%" symbol in a LIKE statement.

SELECT *
FROM prod_legal_unit
WHERE (suite LIKE '%[%]%')

Updated 1:42pm: Here is a list of characters that you can use in a LIKE statement and their function:

% Any string of zero or more characters

_ (underscore) Any single character

[ ] Any single character within the specified range ([a-f]) or set ([abcdef])

[^] Any single character not within the specified range ([^a-f]) or set ([^abcdef])

[Nick's Blog]

Sun, 10 Aug 2003 13:05:41 GMT

The Rozenshtein Method

I have to admit that I am totally hooked on the The Rozenshtein Method. My buddy, Richard Campbell showed it to me a year or two ago and I have been hooked ever since. I recently demoed it at TechED in Dallas, a recent WebCast, VSLive in New York and will be showing it off at TechEd in Malaysia next week. I have gotten lots of email and positive feedback so I decided to blog it here.

Here is how it works. You need a crosstab query. You have to move rows into columns. You also need ANSI 92 SQL that will run in any database.Well there are several ways to do this, but the most generic and one of the most powerful ways is called the Rozenshtein Method, which was developed by the Russian mathematician David Rozenshtein. This technique was taken from his book: Optimizing Transact-SQL : Advanced Programming Techniques.

First letâ€™s look at the desired results. We want to take the orders data from Northwind and pivot the sales date (aggregated by month) as columns with the sum of the total sales in the row grouped by customer. It would look something like this:

CompanyName TotalAmount Jan Feb Marâ€¦(etc)

Company1 100 25 33 10

Company2 467 76 62 87

(etc)

The TSQL query to do this is, go ahead and run it in Northwind in SQL Server:

SELECT CompanyName, SUM((UnitPrice*Quantity)) As TotalAmt,

SUM((UnitPrice*Quantity)*(1- ABS (SIGN(DatePart(mm,OrderDate)-1)))) AS Jan,

SUM((UnitPrice*Quantity)*(1- ABS (SIGN(DatePart(mm,OrderDate)-2)))) AS Feb,

SUM((UnitPrice*Quantity)*(1- ABS (SIGN(DatePart(mm,OrderDate)-3)))) AS Mar,

SUM((UnitPrice*Quantity)*(1- ABS (SIGN(DatePart(mm,OrderDate)-4)))) AS Apr,

SUM((UnitPrice*Quantity)*(1- ABS (SIGN(DatePart(mm,OrderDate)-5)))) AS May,

SUM((UnitPrice*Quantity)*(1- ABS (SIGN(DatePart(mm,OrderDate)-6)))) AS Jun,

SUM((UnitPrice*Quantity)*(1- ABS (SIGN(DatePart(mm,OrderDate)-7)))) AS Jul,

SUM((UnitPrice*Quantity)*(1- ABS (SIGN(DatePart(mm,OrderDate)-8)))) AS Aug,

SUM((UnitPrice*Quantity)*(1- ABS (SIGN(DatePart(mm,OrderDate)-9)))) AS Sep,

SUM((UnitPrice*Quantity)*(1- ABS (SIGN(DatePart(mm,OrderDate)-10)))) AS Oct,

SUM((UnitPrice*Quantity)*(1- ABS (SIGN(DatePart(mm,OrderDate)-11)))) AS Nov,

SUM((UnitPrice*Quantity)*(1- ABS (SIGN(DatePart(mm,OrderDate)-12)))) AS Dec

FROM Customers INNER JOIN

Orders ON Customers.CustomerID = Orders.CustomerID INNER JOIN

[Order Details] ON Orders.OrderID = [Order Details].OrderID

Group By Customers.CompanyName

So how does this work?

This method uses Boolean aggregates, so that each column has a numeric expression that resolves each row as a zero or one and that value (0 or 1) is multiplied by your numeric expression (Like TotalSales or (UnitPrice*Quantity). That is all there is to it, quite simple. But wait, thereâ€™s more to explain:

We want to create columns for each Month in our data. To find a month use DatePart. But we need to subtract the DatePart value (1-12) from the amount youâ€™re looking for (1 for Jan, 2 for Feb, etc) as shown here for January:

DatePart(mm,OrderDate)-1

So that true = zero, false > 0 or < 0. For example if the month you were looking for was January and the DatePart was 1 and you subtract 1 from that value you get 0, which is true. If you are looking for March you would get -2 and that would be false.

Next you have to compute the sign of the expression and get the absolute value like so:

ABS (SIGN(DatePart(mm,OrderDate)-1)))

This will give us a positive value. Remember 0 is still true. Now subtract the value computed from 1 in order to get a 0 or 1 from the value of your expression (the Boolean aggregate). The code is:

(1- ABS (SIGN(DatePart(mm,OrderDate)-1))))

For example if you had March return 3 from the Datepart, 3-1=2 and 1-2 =-1. The absolute value is 1. This will always return 0 or 1. If your expression was zero, the value is now one. If was one, the value is zero.

Last step. Taking the SUM of the Boolean values will give you a count of the values that qualify. So you can find out how many sales you made in Jan, Feb, etc. So now multiply the value by the price and quantity, but remember its now one = true. Take a look here:

SUM((UnitPrice*Quantity)*(1- ABS (SIGN(DatePart(mm,OrderDate)-1)))) AS Jan

If its zero, nothing gets added, if its one, you get the value of the sale. The sum of the total expression is the total of sales for the month. If you have a DatePart that is evaluated to 0 then ((UnitPrice*Quantity)*0) is 0 and those results are ignored in the SUM. If you have a month that matches your expression resolves to 1 and ((UnitPrice*Quantity)*1) is the value of the sale.

How easy!

But wait, thereâ€™s more! Suppose you wanted two values combined? Compute each value down to zero or one separately. Now you can use AND by multiplying, OR by adding (and reduce to 1 or 0 using SIGN).

Ok, have fun!!!

[Stephen Forte's WebBlog]

Sun, 10 Aug 2003 02:05:29 GMT

Bedtime reading.

Stuff I just printed out to read before bed... it'll probably put me right to sleep

Everything below is related, but I haven't printed these out:

Oh man... how exciting. I wish I had more time.

[Keith's Weblog]

Serious SqlServer security problem: Microsoft's state of denial.

Tue, 29 Jul 2003 13:08:56 GMT

Source: Frans Bouma's blog

Several blogs have been posted lately, especially by Paschal, about SqlServer security and .NET. People on the DOTNET-CLR mailing list are already familiar with the problem, but looking at the reactions on Paschal's blogs I can only conclude that the rest of the world, including Microsoft, is in a severe state of denial.

"Close your eyes, deny that there is a problem and you'll see... there is no problem." I have the feeling that's the thought that pops into many heads when they're confronted with the problem about security related to SqlServer and .NET. I can tell you: even if you deny it, the problem will be there, and will stay there, until someone fixes it.

The Problem
Consider you are building a web-application and it will span two machines: a webserver with IIS and your ASP.NET GUI tier and Business logic tier (machine A) and a database server with SqlServer 2000 (machine B). Both machines are used solely for the same application and are running in a DMZ (demilitarized zone) of the corporate firewall. It's obvious that A will connect to B to read or write data. To connect with SqlServer and to be able to do something, you need permissions. There are several possibilities to do this. Let's sum them up in a small list:

Use SqlServer security. This is the easiest way to do it and a lot of people use this. You simply define an account in SqlServer (on machine B) and use that account to connect with SqlServer by specifying that account plus its password in the connection string that is used by A to connect to B.
Use Integrated security. This is the way Microsoft wants you to use: you use the Windows account you're currently logged in with (or better: the security context the application runs in which connects to SqlServer) to connect to SqlServer. You therefor have to map the Windows account on a SqlServer account. You do not have to specify account credentials in the connection string, the connection is 'trusted'.

Both have problems. Let's begin with option 1, the SqlServer security way. Because you have to store credentials in the connection string, you can't hard-code this connection string in the application, otherwise you have to recompile the application when the password changes (some organizations require this, f.e. each month). You can store this connection string in f.e. the web.config file or the .config file of the executable. The problem is that it is readable for a human and mutable. You can crypt it but this degrades performance in some way plus it requires you to have an encrypt utility when changing passwords and you have to update the connection string. There is also a secure local storage called Isolated Storage. You then also have to use a utility to update the connection string when you store the file which contains the string in that isolated storage. In short: it works but there are a lot of disadvantages.

Option 2 doesn't suffer from this problem, you simply specify the account with windows and be done with it. Perfect, right? Well... no. Going back to our 2 machines A and B with our ASP.NET application we can't use this option. The problem is related to "Security on Windows for dummies", Chapter 1, line 1: do not run your internet site on a machine that is part of a domain. You see, the problem is that when you run the ASP.NET application on machine A, it runs under the "My Hands Are Tied"-user ASPNET. That account is a local account. Because every person who understands security and has read Microsoft's excellent papers on the Technet website, will not run the machines in a domain, thus ASPNET on machine A is not known on machine B. The ASP.NET application can't connect to B using a trusted connection simply because ASPNET account isn't defined on B and you then can't make a mapping on B for the ASPNET user.

If you read the SqlServer 2000 security papers, it's clear Microsoft pushes trusted connections and integrated (windows) security over SqlServer security. And understandable. However, in this case (and trust me, this is a very common scenario), with two or more machines which run a complete web-application and control will flow from one machine to the other, initiating from the IIS machine / ASP.NET application, SqlServer security is the only security that actually works. How's that possible? How could Microsoft ignore this issue which is already with us since SqlServer sports windows integrated security? I don't see why Microsoft hasn't fixed this a long time ago. Every person who has written a distributed webapplication with SqlServer knows that keeping the application secure even after a compromise of the front end (the webserver) knows that integrated security is a nice thing for the books but in practise not usable.

Aren't there any ~~'hacks'~~ workarounds?
Well, a few. Let's get a list of these shabby workarounds:

Use a domain. That's right. Simply ignore "Security: Best Practices 101" for now and define a domain for machine A and B, eventually with a separate domain controller (you can also use one of the two machines as a domain controller). This will solve the problem of the unknown user. You simply run the ASP.NET application under a given domain user and because it's a domain user, it is known on the SqlServer machine and can be mapped to a SqlServer account. From A you can use a trusted connection and everything works OK. The problem is... if the webserver is compromised, the SqlServer machine is also compromised, because the website runs as a domain user. That's why every Windows security document recommends to run the webserver not in a domain but as a separate server.
Mirror credentials. Another funny 'solution' is to define the user who is used to run the ASP.NET application also on machine B with the same username and password. So, f.e. define a new password for the ASPNET user on A and define a new local user ASPNET on B with the same password. When the ASP.NET application wants to connect to B using a trusted connection, it can actually log in using the credentials of the security context it runs in on A. Think about this for a minute. We have a logged in user, ASPNET, on A, which has a security token SID and can get access to machine B using that SID or at least the credentials related to that SID. Why is this possible? Apparently Windows security doesn't work with SID's but still with usernames and passwords because a local SID from machine A would otherwise not be recognized on B, because it is not known there. Ok, besides that, it has other problems: the administrator who is in charge of the webserver now also knows security information related to the SqlServer, because the accounts have to be kept in sync. Not all organizations want this. It also makes the point of the locally defined ASPNET user which is not able to do anything rather moot because that locally defined account is able to log into another machine.

Well, what should be the solution then?
For starters, Microsoft should look at common situations where applications are forced to use other security settings than planned or recommended. When they had done this years ago, we wouldn't be in this situation right now. Then, when they got that started up, it should be possible for f.e. SqlServer to verify a given SID token received from another machine with that same machine. In our example, A's locally defined ASPNET user will send its SID over the wire to SqlServer on B when connecting to it using a trusted connection, and SqlServer will then verify with A if this SID is of any good and known by A. Then, inside SqlServer it should be possible to map accounts from A on SqlServer accounts so local defined users on A can have only access to a given SqlServer instance and only to the objects they have rights for defined inside SqlServer. This way, those locally defined users on A cannot and will not have any rights on B. They have only rights inside SqlServer, which is what's required, because an application requires data from that SqlServer instance.

Perhaps it sounds paranoia, but security is something you have to take seriously, very seriously. One compromise on a single box should never be able to escalate to other boxes as well. Perhaps some people now will say I'm wrong and Microsoft has it all figured out and there and there are articles to find how to set it up correctly etc. etc.: please consider for a moment that what I described above is not fantasy, it's reality, and till today, Microsoft hasn't come forward with a solid, simple solution which complies to strong security requirements. Integrated security, trusted connections, I'd like to use them if I could, because the concept is good. However they are not applicable due to reasons I have ventilated in this blog. I truly hope Microsoft will fix this in the (near) future or some brilliant mind has a solution that is secure, simple, reliable and not a shabby workaround.

[Frans Bouma's blog]

Fri, 18 Jul 2003 12:20:03 GMT

Bulk Insert from text file with variable columns

create table ##tbl (line varchar(1000))

bulk insert ##tbl
from 'minidragonc$HUD601_07-15-03.txt'
with (FIRSTROW=1)

--select top 1 Replace(Line, char(9), ',') from ##tbl

declare @tempstr varchar(1000)
declare @col varchar(1000)
declare @createtbl varchar (1000)
declare @loadtbl varchar (1000)
declare @newtblname varchar(1000)

/* ====================================================================

Generates a unique identifier for all the Event Log entries

====================================================================*/

declare @month char(2)
declare @date char(2)
declare @year char(4)
declare @hour char(2)
declare @min char(2)
declare @sec char(2)
declare @msec char(3)

set @month = DATEPART(m, getdate())
if LEN(RTRIM(DATEPART(m, getdate()))) = 1
        set @month = '0'+RTRIM(DATEPART(m, getdate()))
set @date = DATEPART(d, getdate())
if LEN(RTRIM(DATEPART(d, getdate()))) = 1
        set @date = '0'+RTRIM(DATEPART(d, getdate()))
set @year = DATEPART(yyyy, getdate())
set @hour = DATEPART(hh, getdate())
if LEN(RTRIM(DATEPART(hh, getdate()))) < 2
        set @hour = '0'+RTRIM(DATEPART(hh, getdate()))
set @min = DATEPART(mi, getdate())
if LEN(RTRIM(DATEPART(mi, getdate()))) < 2
        set @min = '0'+RTRIM(DATEPART(mi, getdate()))
set @sec = DATEPART(ss, getdate())
if LEN(RTRIM(DATEPART(ss, getdate()))) < 2
        set @sec = '0'+RTRIM(DATEPART(ss, getdate()))
set @msec = DATEPART(ms, getdate())
if LEN(RTRIM(DATEPART(ms, getdate()))) < 3
begin
        if LEN(RTRIM(DATEPART(ms, getdate()))) = 2
                set @msec = '0'+RTRIM(DATEPART(ms, getdate()))
        if LEN(RTRIM(DATEPART(ms, getdate()))) = 1
                set @msec = '00'+RTRIM(DATEPART(ms, getdate()))
end

set @col = ''
set @tempstr = (select top 1 RTRIM(Replace(Line, char(9), ',')) from ##tbl)

while CHARINDEX(',',@tempstr) > 0
begin
set @col = @col+SUBSTRING(@tempstr, 1, CHARINDEX(',',@tempstr)-1)+' varchar(1000),'
set @tempstr = SUBSTRING(@tempstr, CHARINDEX(',',@tempstr)+1, len(@tempstr))
end

set @col = @col+@tempstr+' varchar(1000))'

set @createtbl = 'create table load_'+RTRIM(@month+@date+@year+@hour+@min+@sec)+' ('+@col
set @newtblname = 'load_'+RTRIM(@month+@date+@year+@hour+@min+@sec)

--select @createtbl

drop table ##tbl

exec (@createtbl)

--select @newtblname

set @loadtbl = 'bulk insert '+@newtblname+' from '+char(39)+'wsana157c$tbl.txt'+char(39)+' with (FIRSTROW=2)'

--select @loadtbl

exec (@loadtbl)

Tue, 15 Jul 2003 11:57:49 GMT

xp_readerrorlog

This week each day, I'll cover a new documented and undocumented extended stored procedure. These will be fairly short in description to save space but for the full details, see my book entitled SQL Server 2000 for the Experienced DBA at http://www.amazon.com/exec/obidos/ASIN/0072227885/sqlservercent-20. There is quite a bit of undocumented stored procedures and DBCC commands in the book as well as other advanced topics.

Today's sproc is another useful one that I use in my management scripts to remotely see the SQL Server error log. Xp_readerrorlog will show you a given SQL Server error log and is useful when you want to quickly debug an issue via Query Analyzer without having to open the slower Enterprise Manager. I also like to loop through the error log in ADO using xp_readerrorlog to look for keywords like "ERROR" or "LOGIN FAILED" and act upon those accordingly. To execute the stored procedure, you can run it without any parameters as shown below:

master..xp_readerrorlog

or you can call a given error log from the archive (like ERRORLOG.5) by typing the error log that you wish to see after the stored procedure as shown below:

master..xp_readerrorlog 5

Mon, 14 Jul 2003 14:06:56 GMT

Search all objects in all DBs for code fragments
By: cadebryant - Posted: 6/10/2003 6:48:22 PM (Stored Procedure)
This procedure allows you to search through all objects in all databases on your server for words/phrases in your object code. Very handy for cases in which, for example, a column name on a table has been changed and you need to search your entire server for any sprocs/views/etc. that might reference it.

Syntax: [EXEC] sp_FindCodeStr [@SearchStr=]'', [@PrintOnly=]{0, 1}

Notice that no cursors or temp tables are used in this sproc. Dynamic T-SQL execution appends all the needed statements onto the @sql variable, building the batch in a set-oriented manner, and then the final batch is executed via sp_executesql. As a result, this sproc performs surprisingly well.

Today's procedure is probably one of my favorites. Xp_fixeddrives tells you all the hard drives that are on your SQL Server and how much space you have on each of them. This is a great monitoring script for determining low hard drive space and I use it to raise alerts typically. Another useful application would be to execute it before firing off an extract process to ensure you have space for the ETL before running the load procedure. To execute xp_fixeddrives, use the following syntax:

master..xp_fixeddrives

which will output results similar to this:

drive MB free     
----- ----------- 
C     1773
D     1386
E     12429
F     29276

Mon, 23 Jun 2003 12:45:02 GMT

Source: Keith's Weblog; 6/23/2003; 7:39:11 AM

Trees in SQL.

It turns out there's another way to store hierarchical data in SQL that I didn't know existed. Basically, rather than storing the "parent" for each record (with the root having a NULL parent), it turns out you can store a tree by storing "left" and "right" values for each element of the tree, where left and right are numbers that would be assigned by a preorder traversal of the tree.

Via Simon, check out this article from SitePoint.com by Gijs Van Tulder: Storing Hierarchical Data in a Database, and via a comment on Simon's blog, check out database guru Joe Celko's explanation of the same thing.

The first article has more of a tutorial flavor, and has nice diagrams, but Celko's article goes a little more in depth. Also, Gijs only used a binary tree in his example, so I wasn't sure if it'd work for more-than-binary trees, but Celko's example shows that it can.

The only downside to this technique is that it's more of a pain to insert new rows or delete existing ones, but the benefits seem to outweigh the downsides, especially for large or heavily nested recordsets. This is really a great technique, and I'm glad that it's now in my repetoire. I didn't realize this was possible. Thanks for finding this, Simon

[Keith's Weblog]

Mon, 23 Jun 2003 12:29:13 GMT

Enum Extended Stored Procedures

Digging a little deeper this week into extended stored procedures, we find the xp_enum procedures. These procedures require no parameters but provide a handy bridge to the operating system and is extremely helpful for developers.

Xp_enumgroups will display all NT groups that are currently on your SQL Server. It requires no parameters are the data is loaded into a varchar (255) format (perfect for loading into a temp table for usage).

Xp_enumdsn will display all the DSNs installed on the SQL Server, not the client workstation. Xp_enum_activescriptengines is also a nice extended stored procedure that will display all the scripting engines installed on your server currently. SQL Server uses this to provide you a list of scripting engines in DTS Designer.

Keep in mind that in any extended stored procedure, SQL Server will use the security for whichever account is starting SQL Server. If security is a concern with these extended stored procedures, make sure you lock them down.

Brian Knight
SQLServerCentral.com Co-founder

Sun, 22 Jun 2003 13:09:06 GMT

Source: Stephen Forte's Weblog; 6/22/2003; 7:51:55 AM

Toss Me a Bone Honey....

I have been told by a friend that my use of this expression is getting kinda old. So I will have to give it up. (I am sure that I will pick up something new in Tunisia or Spain.) Before I do that, I am going to use it one last time.

So my company has a Pocket PC (SDE/CF) application that uses a local SQL Server CE on the device with Merge Replication back with an enterprise SQL Server Publication. I have lots of experience making this work, and it works well. I won’t bash the Microsoft SQL Server CE, .NET CF, SDE teams at all.

My problem is that at the office I have this all set up properly. We have a dedicated SQL Server production box and a dedicated IIS box. Life is good. Where things go bad is that I hired a developer who knows nothing about SQL Server CE, SDE, CF, etc, so I am setting up a local sandbox for him to play with while I am in Tunisia and Spain. My goal is to give him the TechEd lab demos created by Kevin Collins, myself and others over the years. Setting up merge replication with a backend SQL Server to a device is pretty easy. The steps are as follows:

Install the SQL Server CE Server Tools on a IIS and SQL Server Machine(s)
Install the SQL Server CE Developer Tools on a Developer Workstation
Install Active Sync 3.5 or higher on the Developer Workstation
Install Visual Studio 2003 (make sure the SDE option is checked in VB & C#) on the Developer Workstation
Create a New Publication of your database via Enterprise Manager-make sure that this publication is for “SQL Server CE” and is set up for merge replication
Run the SQL Server CE Server Tools to configure a Virtual Directory on IIS for the Pocket PC Client to talk to via code
- You do have to make sure that the proper security is set up fro the IUSER_MachineName account, a great security white paper is here.
Create a new Smart Device Application in VS 2003
Programmatically create a database on the device and then sync it back to the backend publication like so:

Dim ceRep As New SqlCeReplication

With ceRep

.Publisher = "KILIMANJARO"

.PublisherDatabase = "BYA_Data"

.PublisherLogin = "sa"

.PublisherPassword = ""

.Publication = "BYA_Data_CE"

.Subscriber = "SQLCENETCFLab"

.SubscriberConnectionString = _ "Provider=Microsoft.SQLServer.OLEDB.CE.2.0;Data Source=\my documents\mycooldatabase.sdf"

.InternetUrl = "http://KILIMANJARO/SSCE_DLL/sscesa20.dll"

'Bring down initial subscription

.Synchronize()

End With

So I have done this a zillion times, install Visual Studio on the development machine along with the SQL Server CE development tools and I am off to the races. This part of course went smooth, except for the fact that I want to sandbox the machine and run everything off it all at once. So I have to make sure IIS 5.0 and SQL Server standard or enterprise is running. Simple you say, just install the SQL Server CE server tools as well on the same machine. The problem is that it took me about two hours to set this up (I have done this a hundred times in less than 15 minutes) because of SERVICE PACK HELL. Basically the server tools would not install since the IIS and SQL Server service packs were too current for the installer on my machine. I did not have to roll back the SPs (that is good!), but I had to dig around and find new installs from Microsoft.

So Microsoft, please TOSS ME A FRIGGIN’ BONE here. Get rid of all of the old install drops and just require SQL Server SP3 to install anything-or create a better error message! I am not asking for much. This is such great technology, I don’t want people to be discouraged from using it due to poor locations of downloads.

[Stephen Forte's Weblog]

Fri, 20 Jun 2003 15:45:52 GMT

Yesterday's question:
You are a DTS developer who has just installed SQL Server Personal Edition and are trying to convert data from Access to SQL Server using the Transform Data task while cleansing the data using the multi-phase feature. For some reason though, you cannot see any of the individual phases when in the Transform Data task under the Transformations tab. How would you make it where you can see the feature?
Answer: Enable the feature in Enterprise Manager by right-clicking on Data Transformation Services | Properties and selecting the appropriate option.
Explaination: To turn on the ability to see the multi-phase data pump feature in DTS Designer, you have to right-click on Data Transformation Services in SQL Server Enterprise Manager and select Properties. Once in the Properties screen select Show Multi-phase Pump in DTS Designer. If this option is disabled, you can still run packages that use the multi-phase data pump feature, you just won't be able to edit it.

Wed, 18 Jun 2003 12:07:05 GMT

Piping the Results of a Query to a Text File

The case where you have to send the results of a query to a text file comes up quite often in my job. Generally, this case can take the form of a maintenance script that you run through Agent nightly and would like to see the results in the morning. In the above example, you can create a CMDEXEC job to run the below command. This will output the results of the query inside c:inputquery.txt to a separate file.

mssql7binnosql -Uloginname -Ppassword -ic:inputquery.txt -oc:outputdiroutput.txt

You can also use -E switch for trusted connection if you don't want to hard code a password into your job. From an Query Analyzer window or inside the stored procedure you can run the above statement with an extended stored procedure called XP_CMDSHELL:

master..xp_cmdshell 'osql -Uloginname -Ppassword -Q"select * from products" -dNorthwind -oc:output.txt'

The -Q parameter in the above syntax runs the query then exits osql. You may also want to add the additional NO_OUTPUT parameter at the end of query as shown below to supress any output to the client:

master..xp_cmdshell 'osql -Usa -Pmisty -q"select * from products" -dNorthwind -oc:output.txt', no_output

There are other methods of piping a query to a text file by using OLE Automation but they are much more complex than this method.

Brian Knight
SQLServerCentral.com Co-Founder

Tue, 17 Jun 2003 21:19:38 GMT

Source: Stephen Forte's Radio Weblog; 6/17/2003; 3:36:16 PM

New York, NY

Long Live TSQL

Why can I never remember the IsNull(foo,0) function in SQL Server. It is an ISNULL or NZ type of function that converts a null value to the item specified, which in this case is a zero. I don't know why I forget this code all the time is that I go back to my Access roots and try to do an NZ() or the Null to Zero function specific to the Access object model. (Old habits die hard!) Well I can usually IM my good friend Al for help, which I did today, but now here is an example of using IsNull in a TSQL string:

update tblSummaryByLocation_WebSublocation
set LocalNewsPaper=IsNUll(LocalNewsPaper1,0)+IsNUll(LocalNewsPaper2,0)+IsNUll(LocalNewsPaper3,0)
WHERE Weekending_ID= @Weekending_ID

I am also sick of using the CASE statement, this code requires me to know something about my data, can' t wait for the Yukon PIVOT keyword:

SELECT     dbo.tlkpWeekEnding.WeekEnding_ID, dbo.tlkpWeekEnding.WeekEnding_DT, dbo.tlkpLocation.Location_ID, dbo.tlkpLocation.Location_NM,
                      dbo.tblLocationSub_WebMapping.WebSublocation_ID,
                      dbo.tblLocationSub_WebMapping.WebSublocation_DS,                       SUM(TotalListings) AS GrandTotal, SUM(CASE tlkpServiceProviders.Service_NM WHEN 'Hot Jobs' THEN TotalListings ELSE 0 END) AS HotJobsTotal,
                      SUM(CASE tlkpServiceProviders.Service_NM WHEN 'Monster' THEN TotalListings ELSE 0 END) AS MonsterTotal,
                      SUM(CASE tlkpServiceProviders.Service_NM WHEN 'Career Builder' THEN TotalListings ELSE 0 END) AS CareerBuilderTotal

FROM         dbo.tblData INNER JOIN
                      dbo.trelServiceURL ON dbo.tblData.URL_ID = dbo.trelServiceURL.URL_ID INNER JOIN
                      dbo.tlkpLocation ON dbo.trelServiceURL.Location_ID = dbo.tlkpLocation.Location_ID INNER JOIN
                      dbo.tlkpServiceProviders ON dbo.trelServiceURL.Service_ID = dbo.tlkpServiceProviders.Service_ID INNER JOIN
                      dbo.tlkpWeekEnding ON dbo.tblData.WeekEnding_ID = dbo.tlkpWeekEnding.WeekEnding_ID INNER JOIN
                      dbo.tblLocationSub_WebMapping ON dbo.tlkpLocation.Location_ID = dbo.tblLocationSub_WebMapping.Location_ID INNER JOIN
                      dbo.tblLocationSub_WebMapping_Detail ON
                      dbo.tblLocationSub_WebMapping.WebSublocation_ID = dbo.tblLocationSub_WebMapping_Detail.WebSublocation_ID INNER JOIN
                      dbo.tblLocationSub ON dbo.trelServiceURL.SubLocation_ID = dbo.tblLocationSub.SubLocation_ID AND
                      dbo.tlkpLocation.Location_ID = dbo.tblLocationSub.Location_ID AND
                      dbo.tblLocationSub_WebMapping_Detail.Sublocation_ID = dbo.tblLocationSub.SubLocation_ID

Where tlkpWeekEnding.weekending_id= @Weekending_ID

GROUP BY dbo.tlkpWeekEnding.WeekEnding_ID, dbo.tlkpWeekEnding.WeekEnding_DT, dbo.tlkpLocation.Location_ID, dbo.tlkpLocation.Location_NM,
dbo.tblLocationSub_WebMapping.WebSublocation_ID, dbo.tblLocationSub_WebMapping.WebSublocation_DS, dbo.tblLocationSub.SubLocation_ID,
dbo.tblLocationSub.SubLocation_DS

[Stephen Forte's Radio Weblog]

More Temporary Tables info

Mon, 16 Jun 2003 17:25:55 GMT

I think that the temporary tables get dropped as soon as the stored
procedure finishes execution.

You could try a simple test in Query Analyzer:
- Open a connection
- Execute the following:
drop proc foo
go
create proc foo as
create table #foo (col1 int)
insert #foo values (1)
select * from #foo
--waitfor delay '1:00:00'
go
exec foo
go
select * from #foo
go
drop table #foo
go
select count(*) from tempdb..sysobjects where name like '#foo%'
go

You will notice that once the procedure execution is over, the temporary
table cannot be referred even from the same connection.

- Now, uncomment the "waitfor", drop & create & execute the proc. From
another connection, execute the following :
select * from #foo
go
drop table #foo
go
select count(*) from tempdb..sysobjects where name like '#foo%'
go

You will notice that there is a table like "#foo", but it cannot be
referenced by anyone else. Also, once you cancel the execution of the proc,
then that table cannot be noticed in the "sysobjects" system table.

The temporary tables should get destroyed after stored procedure execution
are completed, you do not need to "DROP TABLE #foo" at the end of the proc.
You could execute DROP table if you wish to, but it is not necessary. If
you still wish to 'monitor' the temporary tables, you could query the
"tempdb..sysobjects" system table.

Mon, 16 Jun 2003 17:00:39 GMT

The syntax to test if a temporary table already exists or not?

create table #test (
mycol int )

if object_id( 'tempdb..#test' ) is not null
print 'exists'