So check the article both because it’s useful and becasue it serves as a good example of how you can get involved in some of the community activities Martin mentions.

Anyone who has been to a SQL Server User Group meeting will hopefully understand what a SQL Nugget is; for those of you who haven’t my own description of one is a “Something short and interesting regarding SQL Server, the sort of thing that makes you think, “Wow I didn’t know that!”” Having a SQL Nugget slot at the SQL Server User Group meetings works very well, not only does it give the presenters a bit of a break; it also increases the interaction between the attendees, which leads what I think is a very enjoyable atmosphere.

You don’t have to be a seasoned presenter to give a Nugget and quite often it is advantageous to be quite the opposite. For example this is a nugget I picked up at the Leeds Area meeting the other week:

I tend to have my own processes when trying to diagnose problems, and having grown up through what is now quite a few versions of SQL Server, I still tend to use the same or modified versions of scripts I’ve had for a few years, rather than the GUI side of Management Studio. But that’s me being stuck in my old ways; if you have a problem with your system Activity Monitor is a good place to start. In SQL Server 2005 I knew that I could find it on the Management menu

If you double clicked on this you would get a screen like:

In SQL Server 2008, this has now moved. It can be found by right clicking the instance name in Object Explorer; there you will see Activity Monitor on the menu. There is also a button on the standard tool bar for it.

If you click on the Activity Monitor menu option you will see a screen like the following:

Now you may be thinking the fact that Activity Monitor had moved was interesting enough to be a nugget, but it gets better!

Not only do you have a nice graphical display that shows the percent of processor time, number of waiting tasks, database I/O and batch requests; if you display the processes by clicking on the button on the right hand side you get a list similar to the one in SQL Server 2005. Right Clicking on one of the listed processes, gives you the option to Trace the process in SQL Profiler

This will start SQL Profiler with a filter on the given SPID, something I thought was really useful and very interesting.

With SQL Server you always seem to be learning something new, even if it is a small nugget like this. It’s finding out things like this which continue to makes one’s job fresh and pleasing. The SQLBits committee like Nuggets so much, we have decided to run a competition for delegates at SQLBits IV and challenge them to bring along their own nugget and have it recorded for the SQLBits website. After the conference we will vote for the best nugget and the winner will get a prize of an X-Box. This was kindly donated by the Manchester Area SQL Server User Group, which sort of closes the circle and brings us right back to the beginning again!

Take it away Chris Testa O’Neill

SQL Bits goes fourth is on  28th march this time in Manchester. If you decide you would like to get involved like Chris then you need to register as a speaker here and submit your session.  Delegates registering for the event then vote on the sessions they want to see and the best go through.  BTW if you want to see Chris’s session it’s here

The key benefit of is that report consumers can see a unified, integrated view of disparate data sources (AS400/SQL Server/Excel), often for the first time. Further, the integrated data can be presented effectively and easily within a browser by Sharepoint. Since the data is presented in an integrated manner, this can reduce the load on IT to produce reports. This releases the power to create reports into the hands of the end users.  This important feature allows user to manage, produce and edit their own reports in accordance with their requirements, and within their own timescales.

One issue in extracting data from disparate data sources is that people tend to know SQL Server 2005 or AS400 very well – but not both systems.  One issue can focus in getting the two groups of experts together and finding a common language to ensure the successful retrieval of the AS400 data using SSIS. On one hand, AS400 experts may not recognise that SSIS is a key component of ETL in SQL Server. On the other hand, as a SQL Server fan that was familiar with Microsoft SQL Server service packs, it wasn’t particularly obvious to me that IBM produce hotfixes for the AS400 as well. In particular, there is an IBM hotfix specifically for SSIS. In terms of creating a SSIS package which retrieves data from the AS400 and places it into SQL Server, using this hotfix was an essential step to ensuring success.

Another issue in retrieving data from distinct data sources is the troubleshooting process. Due to the integration of two or more systems, it can sometimes be difficult to identify where failures may be occurring.  From the IBM AS400 perspective, it can be difficult to identify issues since, without the hotfix, the situation might exist that no errors are being logged in the trace or log files for AS400. From the SQL Server perspective, it was found that the SSIS package was not able to access customised error files. It was found that this was due to the fact that the designated package login didn’t have appropriate permissions to run. Specifically, the user was not part of the IIS_WPG (IIS Worker Process) group. Once this was resolved, the package could write to the log files. More information about this issue can be found on an excellent forum post.

Advice on creating SSIS packages

To get started, it is worthwhile looking at the Kimball Data Warehouse methodology. Some of the specific SSIS main points are distilled here:

1.       Use an ‘Audit’ table to store information about whole ETL execution process. This is very useful for troubleshooting.

2.       Use a ‘Parent-Child’ package structure.  Here, one main package is the ‘parent’, which executes many smaller packages. Every small package does a small piece of work and loads data in one table. Again, this is useful for identifying any issues in loading the data into the data warehouse.

3.       Naming Conventions are very useful.  It is useful to have package names set to be the same as table name. This simplifies the corresponding package search and clarifies exactly what package does.

It is also useful to look at SSIS package tuning. A good document can be found here on this subject.

The steps involved in using SSIS to access AS400 data can be found here:

1.       AS400 Data Provider - In order to extract data from the AS400 to the SQL Server, it will be necessary to install some special providers. There are a number of these providers available, for example, IBM Client Access Data Provider. In order to ensure consistency, it is worthwhile checking whether your client has other data going from AS400 to SQL Server, since they may already have this provider in-house.

2.       Hotfixes – it may be worthwhile looking at adding hotfixes from the AS400 side, as prescribed above. Further, it is also suggested that it is worthwhile implementing Server 2005 Service Packs where applicable.  In my experience, implementing Service Pack 2 for SQL Server 2005 was useful since it specifically resolved a memory issue.

3.       SSIS Package configuration – An AS400 trigger was set up to export data to specific Change Data Capture (CDC) tables on the AS400. The SSIS package was only required to extract the data, and then clear out the tables when completed successfully. To do this:

a.       An OLE DB source component was deployed to retrieve data from dedicated CDC tables on the AS400.

b.      The data source was set to the ‘IBMDASQL’ connection.

c.       The Data Access mode was set to ‘SQL Command’

d.      Due to the CDC architecture, a simple ‘select *’ SQL Statement was used in order to retrieve data from CDC tables.

e.      It is possible to press the ‘Preview’ button in order to verify the data.

Since the trigger work was all done at the AS400 source, this removed the complexity away from the SSIS package.

To summarise, it is possible to use SSIS to obtain data from non-Microsoft data sources. Here, the actual retrieval of the data from AS400 using SSIS was straightforward once the additional IBM elements were in place. It is important to note that the SSIS packages that retrieve data from the AS400 have been running robustly and successfully now for some time, and this is a mechanism I would consider for data retrieval in the future.

The class System.DBNull  has a static field Value, which represents the sole instance of the class, so in effect [System.DBNull]::Value is the database null object. Like all objects, it has an Equals method. So [System.DBNull]::Value.Equals($DBField) returns true if $DBField contains a null.

How I use it is to declare the null object up front with script scope
 $DBNull = [System.DBNull]::Value
and then use this wherever in the script I need to test for null, thus
 if($Script:DBNull.Equals($DBField))
{
            <null >
}
else
{
            <not null>
}

Leonard Chung, President & CEO

Leonard is an experienced entrepreneur with a particular emphasis on developing and delivering version one products and ideas. Notable past projects include SETI@home, Windows PowerShell, and internet storage company Scale Eight. Past collaborators include RISC/RAID inventor Dr. David Patterson and ACM Turing Award Winner Jim Gray.

Leonard received a B.A. in Computer Science and a B.A. in Cognitive Science from the University of California, Berkeley.

read the article