SQL

SQL Reporting Services Access Denied Error

Dan Matthews — Thu, 28 Feb 2008 11:47:54 GMT

When trying to access your Report Manager, you might see an Access Denied error with an entry in your application log like:

Failed to execute request because the App-Domain could not be created. Error: 0x80070005 Access is denied.

Thankfully it's a simple one to fix. It's caused because ASP.NET cannot access the Reporting Services folders. I'm not sure what the minimum access permissions are but this was on dev so I simply gave the Network Service full control on my 'ReportManager' and 'ReportServer' folders and that sorted things.

Emptying the Deleted Items in MCMS

Dan Matthews — Fri, 16 Nov 2007 16:15:49 GMT

So you might have an MCMS site that has been kicking around for a few years... lots of content has been deleted. Site is getting sluggish. You go into Site Manager to empty the deleted items and everything you click takes 1 minute to respond. Emptying the deleted items is useless - it just crashes. The reason for this, I think, is that it retrieves XML from MCMS and when trying to manipulate the huge XML files in the XML DOM it just falls over. The DOM does have a maximum logical size of XML it can manipulate before performance degrades quickly.

What to do?

Well it's a nasty one as there is no API call to empty the deleted items. Microsoft - who I've logged support calls with about this - have taken over a year to come back with nothing. Basically, you're on your own.

Now the MCMS schema is a bit nasty and if you do anything to the MCMS database directly you may invalidate your Microsoft support. Having said that, it's the only way I could find to empty the deleted items without Site Manager.

Here is the script I wrote and used. Use it ENTIRELY at your own risk. I suggest you figure out what it's doing before you run it. Good luck!

-- properties (historical)

print 'deleting properties (historical)'

delete from NodeProperty where NodeId in
(select Id from Node where ArchiveSourceGUID in
(select FollowGUID from Node where DeletedWhen is not null and Type=16))

-- resources (historical)

print 'deleting resources (historical)'

delete from NodeResource where NodeId in
(select Id from Node where ArchiveSourceGUID in
(select FollowGUID from Node where DeletedWhen is not null and Type=16))

-- roles (historical)

print 'deleting roles (historical)'

delete from NodeRole where NodeId in
(select Id from Node where ArchiveSourceGUID in
(select FollowGUID from Node where DeletedWhen is not null and Type=16))

-- placeholder content (historical)

print 'deleting placeholder content (historical)'

delete from NodePlaceholderContent where NodeId in
(select Id from Node where ArchiveSourceGUID in
(select FollowGUID from Node where DeletedWhen is not null and Type=16))

-- placeholders (historical)

print 'deleting placeholders (historical)'

delete from NodePlaceholder where NodeId in
(select Id from Node where ArchiveSourceGUID in
(select FollowGUID from Node where DeletedWhen is not null and Type=16))

-- postings (historical)

print 'deleting postings (historical)'

delete from Node where ArchiveSourceGUID in
(select FollowGUID from Node where DeletedWhen is not null and Type=16)

-- properties (current)

print 'deleting properties (current)'

delete from NodeProperty where NodeId in
(select Id from Node where NodeGUID in
(select FollowGUID from Node where DeletedWhen is not null and Type=16))

-- resources (current)

print 'deleting resources (current)'

delete from NodeResource where NodeId in
(select Id from Node where NodeGUID in
(select FollowGUID from Node where DeletedWhen is not null and Type=16))

-- roles (current)

print 'deleting roles (current)'

delete from NodeRole where NodeId in
(select Id from Node where NodeGUID in
(select FollowGUID from Node where DeletedWhen is not null and Type=16))

-- placeholder content (current)

print 'deleting placeholder content (current)'

delete from NodePlaceholderContent where NodeId in
(select Id from Node where NodeGUID in
(select FollowGUID from Node where DeletedWhen is not null and Type=16))

-- placeholders (current)

print 'deleting placeholders (current)'

delete from NodePlaceholder where NodeId in
(select Id from Node where NodeGUID in
(select FollowGUID from Node where DeletedWhen is not null and Type=16))

-- postings (current)

print 'deleting postings (current)'

delete from Node where NodeGUID in
(select FollowGUID from Node where DeletedWhen is not null and Type=16)

-- pages

print 'deleting pages'

delete from Node where DeletedWhen is not null and Type=16

-- channel properties

print 'deleting channel properties'

delete from NodeProperty where NodeId in
(select Id from Node where DeletedWhen is not null and Type=4)

-- channel roles

print 'deleting channel roles'

delete from NodeRole where NodeId in
(select Id from Node where DeletedWhen is not null and Type=4)

-- channels

print 'deleting channels'

delete from Node where DeletedWhen is not null and Type=4

EPiServer 4.6.x and SQL Server Express 2005

Dan Matthews — Wed, 06 Jun 2007 10:46:52 GMT

...and straight off I have something to share with you :)

If you're installing using EPiServer manager and using SQL Server 2005 Express, you need to be aware of the following, otherwise you get all sorts of 'SQL Server unavailable' and user authentication errors:

1) Make sure you NAME THE INSTANCE in the install, otherwise it will install on your default instance (which in my case, stupidly, was an MSDE instance!)

2) Make sure you have both Shared Memory and TCP/IP turned on in your SQL2005 Configuration. The installation uses Shared Memory, but the site itself uses TCP/IP.

3) Make sure mixed-mode authentication is turned on for your SQL Express instance

4) Make sure that your website is running as ASP.NET1.1 during the install (do the .NET2 templates and stuff afterwards)

Avoiding SQL Cursors

Dan Matthews — Fri, 11 May 2007 10:53:08 GMT

One of my pet hates is SQL Server cursors. Yes, I know that they are part of the product for a reason, and I know that they are very handy. So why do I hate them, and what can be done to avoid them? Are they a necessary evil? I developed a technique to avoid them a few years ago, and some others people have since designed some techniques as well, such as on this post. These other techniques are great, but my style of doing things has the one advantage that it can be repeated and nested in complex ways because of the use of variable tables... as you'll see below.

Well, lets first create some test data. I used a server with both SQL2000 and SQL2005 server on to do some tests just to show this technique works on both. I created an empty database with an empty table, and then added 1,000 random numbers between the value of 1-100 into the table. The script I used to create the table is below:

CREATE TABLE [dbo].[test] (
[testid] [int] IDENTITY (1, 1) NOT NULL ,
[randnum] [int] NOT NULL
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[test] WITH NOCHECK ADD
CONSTRAINT [PK_test] PRIMARY KEY CLUSTERED
(
[testid]
) ON [PRIMARY]
GO

I then constructed two very simple queries which took a number as a parameter and returned the number of columns matching that number. Yes, I know that I could have done a single SELECT to get that, but that's not the point of the exercise :) Where this technique IS essential is where you find yourself doing complex nested group-bys and start to think about pivots and the like (and especially where there's no reliable numeric ID column) Basically, where row-by-row operations are needed.

Firstly, the cursor script I used looked like this:

DECLARE @iCheckNumber int,
@iCurrentNumber int,
@iNumberCount int

SELECT @iCheckNumber = 35,
@iNumberCount = 0

DECLARE testnum CURSOR FOR

SELECT randnum FROM test

OPEN testnum

FETCH testnum INTO @iCurrentNumber

WHILE @@FETCH_STATUS = 0
BEGIN
FETCH testnum INTO @iCurrentNumber

IF @iCurrentNumber = @iCheckNumber
BEGIN
SELECT @iNumberCount = @iNumberCount + 1
END
END

CLOSE testnum

DEALLOCATE testnum

SELECT @iCurrentNumber

As you can see, it's a pretty standard cursor script. I ran it from Query Analyzer (2000) or Management Studio (2005) and it ran fine and returned the results I wanted. So how do I do the same kind of thing without cursors and without creating umpteen temporary tables? Well, I can use the T-SQL support for loops, and variable tables, as below:

DECLARE @iCheckNumber int,
  @iCurrentNumber int,
  @iNumberCount int,
  @iCurrentRow int

SELECT @iCheckNumber = 35,
@iNumberCount = 0

DECLARE @temptest AS TABLE
(
iRowID int identity(1,1),
randnum int
)

INSERT INTO @temptest (randnum)
SELECT randnum FROM test

SELECT @iCurrentRow = 1

WHILE @iCurrentRow < (SELECT COUNT(*) FROM test)
BEGIN
IF (SELECT randnum FROM @temptest WHERE iRowID = @iCurrentRow) = @iCheckNumber
BEGIN
SELECT @iNumberCount = @iNumberCount + 1
END

SELECT @iCurrentRow = @iCurrentRow + 1

print @iCurrentRow
END

Note that I'm creating an identity column on my temporary table. This makes it ideal for writing queries where your data has no SEQUENTIAL numeric identity column already. One common use for this is with paging. Imagine you have a table with an ID and Name column. You want to pull back your names 500 at a time. You can get the first 500 no problem, just do a SELECT TOP 500. When you come to get 500-1000 you have problems - and that's where a cursor is normally used.

With my technique, you can put all your unique IDs in the temporary table, and then just iterate through the row numbers you want.

Note that the example I used here probably performs better as a cursor because it is so simple, but that's not a true reflection of cursors. They perform badly, even in 2005, and the more complex they get then, in my experience, the more useful it is to avoid

ReturnValue from a TableAdapter (ASP.NET2)

Dan Matthews — Thu, 03 May 2007 08:42:19 GMT

We've been using TableAdapters created using the XSD designer in VS2005 lately, and have found they have a couple of gotchas.

For example, one limitation of a TableAdapter is the lack of support for SQL stored proc return values when using a non-scalar stored proc call - or at least, lack of any useful access to them. You'd expect that maybe the return value would be the return from the auto-genned function, but you'd be wrong. The return is actually the number of rows affected, and that in itself is useless if you're turning row count off in the stored proc (as many do).

So maybe the ReturnValue is a property on the TableAdapter? Again, no... you can use 'out' parameters fine (just pass the variable as ref to the auto-genned function), but thats not very nice. I don't want to throw away the return value concept and use 'out' params just because the TableAdapter isn't clever enough.

So, what to do? There's some good blog posts around on the technique, but most of them only work really well when you have just one or two stored procs and table adapters (see this blog post for an example. In the solutions we're building, we often have lots. And lots. It's a heady mixture of designer work and cut-paste fest. Ugly maybe, but it does allow flexibility. This meant we had to make some kind of vaguely generic function to get the ReturnValue available to our UI code layer.

To achieve this, we made use of the TableAdapter partial classes that the XSD creates for us. Let's say that we have a set of stored procs to do with orders. You might have:

AddOrder
UpdateOrder
DeleteOrder
GetOrder
GetOrders

You'd probably only be bothered with the return value from the stored procs that actually wrote date - the top 3. Lets say they are returning an error code, like 0 for success, 1 if they can't find the specified record, 2 if it will break a constraint etc. What you can then do is create your TableAdapter queries for each function - lets assume you called them all the same thing as their underlying stored procs. Let's say our TableAdapter is called OrderTableAdapter.

We then need to do our clever jiggery pokery. Just outside our partial class for OrderTableAdapter, we put an enumeration, like so:

    public enum OrderCommandType
    {
        Add,
        Update,
        Delete,
        Get,
        GetAll
    }

We do this so that it's a cleaner solution in our data layer, where we'll have a manager class (I hate lobbing strings around where an enum would be better). Following this enum declaration, we have the main worker function which is a method called 'ReturnValue' which takes one parameter - the OrderCommandType. For simplicity, I've written comments inline in the method below.

partial class OrderTableAdapter
    {
        public int ReturnValue(OrderCommandType Command)
        {
            // get the return value for the appropriate command
            switch (Command)
            {
                case OrderCommandType.Add:

// the first param is the SQL command collection of the TableAdapter, the second param is the stored proc name that we want the return value from
return TableAdapterHelper.GetReturnValue(this.CommandCollection, "AddOrder");

case OrderCommandType.Update:

return TableAdapterHelper.GetReturnValue(this.CommandCollection, "UpdateOrder");

case OrderCommandType.Delete:

return TableAdapterHelper.GetReturnValue(this.CommandCollection, "DeleteOrder");

default:

                    // for cleanliness, throw an error if someone tries to get the ReturnValue from one of the method types that we have decided shouldn't return a value
                    throw new Exception("OrderCommandType requested does not support return values");
            }
        }
    }

You'll see I refer to a TableAdapterHelper - this is important as it's the bit that actually digs out the ReturnValue itself...

    public static class TableAdapterHelper
    {
        public static int GetReturnValue(SqlCommand[] aCommands, string sCommandText)
        {
            // now lets find that commmand

            // iterate through all command objects in the command collection
            foreach (SqlCommand oCommand in aCommands)
            {
                // see if the stored proc name matches
                if (oCommand.CommandText.Equals(string.Format("dbo.{0}", sCommandText)))
                {
                    if (oCommand.Parameters != null)
                    {
                        // loop thru all params
                        foreach (SqlParameter oParam in oCommand.Parameters)
                        {
                            // find the param with a direction of ReturnValue (should only ever be one)
                            if (oParam.Direction == System.Data.ParameterDirection.ReturnValue)
                            {
                                if (oParam.Value == DBNull.Value || oParam.Value == null) return 0; // assume dbnull is success

                                return (int)oParam.Value;
                            }
                        }
                    }
                }
            }

            throw new Exception("Could not locate Return Value");
        }
    }

As you'll see, my technique works on the basis that the stored proc names are known and unique across commands in a single TableAdapter, which should normally be the case. You might find it ugly that the stored proc names are embedded in code - but they're in the XSD anyway so it's still containing in one place.

So the final part of the jigsaw is the actual call itself, and the getting of the ReturnValue. Here is an example of how to make the call. Note that I've made OrderID an out param. I like to throw an error if the SQL error code is non-zero.

OrderTableAdapter ta = new OrderTableAdapter();

int iRowsAffected = ta.AddOrder(ref OrderID, OrderCode, CustomerID, OrderLineID);

int iErrorCode = ta.ReturnValue(OrderCommandType.Add);

if(iErrorCode != 0)
{
// throw an exception here
}

You can also combine this technique with 'out' param error messages and the like to make a very powerful below-data layer in the stored procs.

SQL Express 2005 installation

Dan Matthews — Thu, 26 Apr 2007 09:33:03 GMT

When installing SQL Server Express 2005, you may get an error saying something like:

An installation package for the product Microsoft SQL Server Native Client cannot be found. Try the installation again using a valid copy of the installation package 'sqlncli.msi'.

Irritatingly, it only says this after the installation file has already extracted, installed support files, checked the system, checked pre-reqs, initialised main installation, prompted you for config and installed a bunch of things (which it then rolls back). It's 5-10 mins until you get the error and there's no 'retry'.

Anyway, at least it's easy to fix :) I read a couple of articles on Microsoft and MSDN Forums which weren't THAT helpful. They seem to contain too much info. I found that I could fix the error by doing this (note - I was installing on a box which already had full SQL2000 installed... it might well not work if you are installing 'clean')

Extract the SQL Express MSI to a temp folder. (SQLEXPR32.EXE /X:TEMPFOLDER). Then find the "SQLNCLI.MSI" file that it extracted into the 'Setup' folder. Run it, and when prompted, choose to Repair the installation. Now re-run the SQL Express installation, and it should work fine!