Author Archives: Alex Angas

SQL Server index tuning flavoured with Entity Framework and WCF Data Services

I’m working on a particularly database intensive application at the moment. We use Entity Framework code first for our back-end database reads and writes, and have a WCF Data Services wrapper for REST read access from the UI.

Over the last few weeks as load has increased I’ve started noticing the occasional SQL deadlock and timeout on production. Suddenly yesterday we reached some sort of tipping point and were inundated with timeouts. The cause of most of these was found just by running SQL Profiler and watching some unnecessary queries spill down the screen (multiple functions inside a view, bad idea). Once the chaos was largely over, I started looking at whether our database indexes were actually useful and how to verify this with EF and WCF DS.

Configuring SQL Profiler for Entity Framework

These are the SQL Profiler settings I found worked best to capture both EF and WCF DS queries (with Show All Columns ticked):

SP:StmtCompleted
SP:StmtStarting
SQL:BatchCompleted
SQL:BatchStarting

This combination allows you to see CPU time and how long statements took, as well as then letting you load the trace into Database Tuning Advisor (DTA). If you want to check for timeouts and deadlocks as well, make sure you include:

Deadlock graph
Lock:Deadlock
Lock:Deadlock Chain
Lock:Timeout (timeout > 0)

Back to the Database Tuning Advisor, it specifically requires SQL:BatchCompleted and SP:StmtCompleted. The details of how to get that running is on MSDN. Set the SQL Profiler trace to output to a file (if you want to analyse on your local machine) or database table. Let it run for a few hours while the tasks you want to optimise are being performed by your users. If you’re game you can run this on production for more accurate results, but a test environment is preferred provided you can recreate a typical load.

Analyzing SQL Profiler results in the Database Tuning Advisor

I found the most useful things from the DTA are the SQL script of recommendations in combination with the “Index usage report (recommended)”. These will get you 90% of the way to some quick optimizations. After running the DTA, save the SQL script from the Actions / Save Recommendations menu. Then switch over to the Reports tab, choose the report just mentioned, and then right-click on the table of results and click “Export To File” (this feature is not obvious!).

Copy both files over to your local machine. Open the script in a text editor, and use Excel to open the XML report. Sort by “PercentUsage” and look at how the indexes you already have compare with the DTA recommendations (that start with _dta_index). You can easily find its recommended indexes in the SQL script and adapt them to your needs – just give them good names! Also consider dropping the indexes that don’t show up at all as each database write usually causes an update of the index which can take time and cause further timeout issues.

Do your research before developing with InfoPath

Leave a reply

Disclaimer: When I first drafted this post back in May 2011 I was not aware that our sister company was developing a competitor to InfoPath. When I did find out, I couldn’t say anything due to NDA. I’ve held off publishing this until that product’s been announced in order to be as transparent as possible.

I’ve worked on numerous InfoPath projects over the last two years, covering each version – 2003, 2007 and 2010. As time has gone on, I’ve started to develop a twitch whenever someone mentions “InfoPath”. Now to be clear, the product has its place and there are times when it is appropriate for use. However there are also things to be very cautious of, even to the point where alternatives should be considered such as custom development.

I’ve tried to tone down this post, but there is a fair bit of frustration here that is hard to eradicate! Here’s my top list of gotchas.

Business logic is hidden

The default way that InfoPath names its data structures as a user creates them looks like this: field23 or group22. The UI never encourages the user to give fields names that describe their purpose. You could argue it actively discourages it by introducing the friction of of a dialog before a field can be renamed. It would be nice if a field was in “rename mode” when a control associated with it was first dragged onto the form!

To add behaviour to a form, the user attaches “rules” to fields. This is an n rules to 1 field relationship. As it’s not unusual to complete the design of a form with up to 50 or even many more fields, many of these rules make up the end result, spread throughout the form. This causes serious maintenance difficulties as the only good UI for finding and working on these rules is on a per-field basis. There is a Logic Inspector “feature” provided with InfoPath but its UI is very poorly designed and there’s no way to relate rules to each other. This makes it easy to forget what a rule is there for.

Using InfoPath seems like such an easy solution. In just a few clicks you can have a very powerful form without thinking about it! And therein lies the rub. I’d argue that many people don’t put in the effort to properly think through the design of a form, and wind up with unwieldy beasts of complexity. InfoPath provides no assistance in making a form self-documenting and expects you to remember what field23 is for, or Rule 5. Over time we can end up with no-one really knowing how the thing is supposed to work, and forced to unravel a web of rules and fields to find out.

The loaded gun feature – custom code

The most innocent of requirements can require custom code and sometimes aren’t discovered until later down the track once a form has been largely developed and you’re locked in to the InfoPath platform. The problem with code is that it requires a developer, adds another level of complexity, and changes the deployment method to SharePoint entirely (requiring involvement from the IT department’s SharePoint administrator). Adding code is something that even Microsoft don’t recommend:

Create InfoPath forms with as little code as possible, and put the bulk of your code into middle tier services and workflows.

If you’re adding code anyway, think about why you are using InfoPath and not developing a custom solution. If your deployment target is SharePoint, newer features such as LINQ to SharePoint are very easy to implement.

Do you prefer a messy or broken form?

If you have developed a form and decide one part of it has to be deleted or replaced with something else then you have two options:

You can leave the old fields and groups unused in the underlying data structure but not show them. This means over time you’ll have leftover cruft with a purpose that no-one can remember.
You can delete them and break the ability to open any older forms. Removing aspects of the data structure is a strict no-no and InfoPath cannot handle this situation.

The multiple environment nightmare

InfoPath loves to hard-code references to everything, particularly data sources, so if you want to follow a best practice process of deploying to a test environment first, you’re asking for more maintenance headaches. Some of the issues are alleviated by deploying a form as a feature that can dynamically correct these references but this requires Visual Studio and locks you into this method of deployment for the life of the form.

Then there’s the way republishing the same form across multiple environments will almost certainly cause confusion to both you and SharePoint as column names are not kept identical. This is an issue documented in Microsoft KB article “Columns published from InfoPath fields are recreated when the same InfoPath form template is re-published to more than one document libraries in a SharePoint site”.

It’s also possible to hit problems with InfoPath’s caching. This tries to be helpful but sometimes can be overzealous or just plain gets confused between different environments. Unfortunately it can result in your testers using the test version of a form in production before the update has been deployed!

Too many bugs

You’re never gonna know when one’s going to bite you and cost serious time, again and again and again. There are bugs and unexpected behaviour in the client, when deploying forms with code, and in Forms Services. Pretty embarrassing when you think you have a form “just right” and it breaks in front of your demonstration audience.

The InfoPath sales pitch

Microsoft’s selling point is that InfoPath is part of Office and any savvy business user can maintain these forms. However this greatly depends on the complexity of the form and the user’s expertise. Many people struggle as forms get more complicated for the reasons mentioned here (plus more), and introducing multiple environments or custom code makes it nigh impossible.

As mentioned earlier, InfoPath has its place. Make sure your reasons for using it are the right ones.

Enough!

I could go on! But hopefully this gives you some things to think about before falling into the InfoPath deep end. InfoPath has its place for simpler solutions and usually doesn’t require a developer resource. Just be careful not to let it cost you dearly later. Fingers crossed that Microsoft will change some fundamental flaws the product has had for a while now in the next version.

Developing for a load balanced SharePoint environment

Leave a reply

If you are going to deploy to a load balanced environment, a big plus is being able to develop in one. Unfortunately a lot of us don’t have that luxury! Here are some key points to help out.

Managing state

Always rely on SharePoint’s central store – the database. Don’t try and store data on the file system as you will never be sure which server has what copy. Use lists for data that should be exposed to administrators and users. Use SPPersistedObject or the patterns & practices Application Setting Manager for application configuration.

Caching

This is just another method of storing state, albeit one that’s faster (yet limited in resources)! Be aware when using ASP.NET caching that every server will cache your data separately in its own copy of RAM. These will get out of sync resulting in inconsistencies that you will need to handle. You may find AppFabric Caching as described by Wictor Wilén a good solution to this problem.

Thread safety

Never store rich objects that aren’t thread safe such as SPListItem in the cache or any other form of state. Aside from potentially taking up unnecessary space, these objects won’t work properly once deserialized. Introducing caching also opens up your application to potential threading issues, as explained in “Understanding the Potential Pitfalls of Thread Synchronization” in this best practices article. You don’t need to use System.Threading to be multithreading!

Testing

Even if you can’t develop in a load balanced environment, it really pays to test in one. A lot of situations just can’t be reproduced otherwise! I strongly recommend to ensure your production environment always closely matches test in configuration (even if number of servers is unreasonable).

Conclusion

In summary: always store data in the database to avoid problems with different servers accessing the same content and keep any caching simple and stateless. Oh, and be sure to thoroughly test!

Tailoring SP2010 p&p logging to your application

Leave a reply

Back in our last post, we saw an intro to the logging power found in the SP 2010 patterns & practices library. Now, let’s make it our own.

Defining your own areas and categories

The out-of-the-box behaviour is fine, but it’s much nicer for both end user and developer to see the actual application name causing the exception, rather than the generic “Patterns and Practices”. No problem, you can define your own areas and categories! What does this mean? Examine a ULS log file and you’ll see at the top a series of column headers. “Area” is typically used for the a major piece of functionality or application name. “Category” is some component of that functionality. For logging to the Event Viewer, the Source column is used for “Area”, and “Category” is the first line of the log entry.

The many ILogger methods

Before continuing, let’s examine how we use a custom area and category when calling the ILogger. If you have a look at its interface, you’ll find several variations of two methods. LogToOperations writes to both the ULS trace log and the Event Viewer. TraceToDeveloper writes to the trace log only. Some variations allow you to specify a category and others don’t. At this point, you really want to look at the many options and narrow down the list to one or two that are going to be most useful to you. I generally only use the following depending on whether I’m logging exceptions or information:

void LogToOperations(Exception exception, int eventId, EventSeverity severity, string category);
void LogToOperations(string message, string category);

Notice the category parameter which is where we set both the area and category to use. The supplied string here needs to be of the format “Area/Category“. This is fairly distasteful in design and much like a “magic number“, but that’s the way the API has been written. I recommend creating a LoggingHelper class that abstracts this away and reduces the risk of making a mistake.

Registering the areas and categories

There is one last trick to perform before using these custom areas and categories. They must be provisioned as part of a farm level feature. This is primarily because updates are made to the SharePoint configuration database which requires execution by an account with farm level permissions. It’s also because registering new sources for the Event Viewer to use must be done by a user with permissions to write to the Windows registry. Executing this registration as a farm-level event receiver should alleviate these issues (unless you’re deploying to a locked down environment where you may have some problems).

There is sample code on how to register areas and categories in the SharePoint Guidance documentation. (There’s also plenty of other great stuff there about how the logger works and I recommend taking a few minutes to read it.) One extra thing to take note of if you plan on logging to the Event Viewer in a multi-server farm is that this registration needs to take place on each server in the farm. There are instructions on how to do this by lead SharePoint p&p developer Chris Keyser.

Segue – suggestions

As you would have gathered, this library is not perfect. Here’s some thoughts on gotchas and what I feel could be improved:

The ILogger interface contains too many method signatures which causes confusion. Most developers will only settle on their chosen one or two. I’d like to see a simple entity-style class used for specifying logging parameters instead of the many options given.
Using a ‘magic number’ style string format to select an area and category is error prone. Area and category should be separated, and preferably strongly typed.
It’s clear to see the ILogger interface has been designed around logging to the ULS and Event Log. This makes it not as adaptable to other scenarios. Again, using an entity-style class for parameters would help make it more generic.
To register your own custom areas and categories, a farm feature is required so that enough permissions are available to write to the Windows registry. In multi-server farms there is added complexity.

On the plus side, a lot of these issues only need to be resolved once.

Conclusion

I really like the logging functionality provided with the patterns & practices library. It’s generally easy to use and certainly powerful. There are some issues, but it’s a great way to get exposure to the benefits of this library and immediately reap rewards!

Intro to SharePoint 2010 patterns & practices – Logging

4 Replies

Microsoft’s patterns & practices library for SharePoint 2010 contains plenty of useful information and tools. One of the simplest things you can start using right now is its logging functionality. Check out these handy features:

Log to both the ULS trace logs and the Windows Event Viewer
Define your own logging categories so they appear under your application’s name everywhere
Support for logging from the sandbox via a provided proxy
Configure log event throttling using the out-of-the-box Diagnostic Logging page in Central Administration
Contextual information such as current URL and logged in user is automatically added to log entries
Don’t worry about logging long messages or correlation IDs, it’s all handled for you
Use the provided logging interface to easily write your own logger
Service locator provided means almost no code changes when changing to a different logger (for a future blog post)

If you’re a developer that’s never used the library before, this post helps you dip your toes in the water and harness this logging power!

Getting started

The p&p release is a little confusing. There’s the CodePlex project, which links to various components and where you should ask for help or log any bugs you find. However the code is not kept there – download that from MS Downloads. You’ll want to keep an eye on this page for updates as they aren’t announced anywhere that I’ve found.

Once extracted to your development server, you need to build the library. Everything is open source apart from the service locator (for a later blog post). The solution to build can be found at Source\SharePoint 2010\Microsoft.Practices.SharePoint.sln.

Build this project, then copy the output Microsoft.Practices.ServiceLocation.dll and Microsoft.Practices.SharePoint.Common.dll to your project and reference them.

Log away!

Using the logger is pretty easy. First, add these using statements everywhere you wish to log:

using Microsoft.Practices.SharePoint.Common.Logging;
using Microsoft.Practices.SharePoint.Common.ServiceLocation;

Then declare the logger as a field and obtain a reference to it:

ILogger _logger = SharePointServiceLocator.GetCurrent().GetInstance<ILogger>();

Now let’s log an exception…

Exception ex = new ApplicationException("This is my test exception");
_logger.LogToOperations(ex);

…and see what appears in the ULS log…

09/08/2010 20:15:34.66 w3wp.exe (0x15D8) 0x0EF0 Patterns and Practices SharePoint Guidance 0000 Information Category: SharePoint Guidance: An exception has occurred. ExceptionType: ‘ApplicationException’ ExceptionMessage: ‘This is my test exception’ StackTrace: ” Source: ” TargetSite: ” Additional Information: Request TimeStamp: ’2010-09-08T20:15:33.2171690+09:30′ UserName: ‘AA\Administrator’ Request URL: ‘http://aasp2010dev:31000/default.aspx?PageView=Shared&InitialTabId=Ribbon.WebPartPage&VisibilityContext=WSSWebPartPage’ User Agent: ‘Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET4.0C; .NET4.0E; InfoPath.3; .NET CLR 3.5.30729; .NET CLR 3.0.30729)’ Originating IP address: ’127.0.0.1′ 2cc97a55-1c4d-4e22-b145-4de9a3fdf6e1

…and Event Viewer:

Log Name: Application Source: Patterns and Practices Date: 8/09/2010 8:15:34 PM Event ID: 0 Task Category: None Level: Information Keywords: Classic User: N/A Computer: aasp2010dev.aa.com Description: Category: SharePoint Guidance: An exception has occurred. ExceptionType: 'ApplicationException' ExceptionMessage: 'This is my test exception' StackTrace: '' Source: '' TargetSite: ''

(many other details removed for brevity)

Here you can see the benefits these simple steps have already given – lots of context relating to exception to help diagnose the problem!

Logging – make it happen!

That’s it for now, but we’ll be exploring a lot more about this library in the next blog post. Remember – you owe it to yourself and your users to log appropriately. Ease the pain of bugs found in production code!

Download and references:

Analysis of the Oracle Hyperion Web Part

Leave a reply

This is a post I originally wrote in July 2009 and never got around to properly completing. Because of its age I considered binning it altogether however a quick web search seems to turn up that nothing has changed for this humble web part. This is more of a rant about vendors that can’t be bothered to integrate their products with SharePoint using best practices. The person that ends up suffering is “the SharePoint guy/gal” who is lumped with deploying this rubbish. Hopefully it helps someone else out there that’s stuck in the same boat I once was.

Rewind to July 2009

I was recently given the task of deploying the Oracle Hyperion web part for testing in one of our SharePoint sites. There was no formal requirement for this, it was simply requested because there appears to be no documentation or information available on what functionality this mysterious web part can provide. What better way to find out than to deploy it for testing, right? There are even quite detailed instructions available!

Well stop right there, folks. In fact before you read any further, my recommendation is to run far, far away from this unusual piece of technology. Why? Well let’s start with the high-level changes you’ll need to make to your SharePoint environment:

Add the web part itself
Configure single sign-on (SSO) – makes sense as Oracle is an external product
Create a ‘proxy page’ – a virtual IIS application inside your SharePoint application
Install a custom HTTP handler
Create a custom database

Hmmm… seems rather unusual so far (particularly that custom database – don’t we already have data stores in both SharePoint and Oracle?). But then read the fine print as it describes three best practice no-nos all on one page (that’s page 71 if you’re following along readers) without even so much as to explain what effect the changes will have.

Set the trust level to Full.
Say goodbye to security in your SharePoint farm right here. With trust level set to Full, custom code can run without restriction and do whatever it likes. Really Bad Idea. Oracle, please look into Code Access Security.
Replace the default SQL Server session state provider for SharePoint.
I’ll be honest. I have no idea what they are doing here or why. All I know is that the chances of support from Microsoft on such a fundamental change to how session state works in SharePoint has to be zero.
Comment out the PublishingHttpModule.
Say goodbye to one of the best features in SharePoint – publishing pages. For yet another strange and unexplained reason, this has to go. Not sure if they put it back somewhere with their custom code, this isn’t mentioned.

Now follow through almost twenty pages, some with screenshots, to configure this nightmare, and that doesn’t included setting up SSO. I like to think I’m pretty good at puzzling out this sort of thing, but this baby has got me beat.

Things I found that might help others… Add the server hosting SharePoint to the Local Intranet zone in Internet Explorer security settings. Otherwise, you might encounter an “Invalid index” message while browsing the repository in Internet Explorer. Also, uninstall the Enhanced Security Configuration from Windows Server to prevent logon issues.

I wonder if anyone, anywhere has been able to successfully deploy this thing? More to the point, why did Oracle bother to even develop it?

Why it’s an exciting time to be part of SharePoint Overflow!

Leave a reply

SharePoint Overflow started as one of the first Stack Exchange sites (running version 1.0). It’s also been one of the most successful. We’ve been able to attract some fantastic contributors including several MVPs and our traffic stats have continuously increased.

When the discontinuation of the original Stack Exchange business model was announced, I felt plunged into the wilderness and lost motivation in the site for a little while. Suddenly, calling this community our own while running it on the awesome platform that powered sites such as Stack Overflow appeared impossible come April 13 2011. Stack Exchange 2.0 would be owned by the Stack Overflow team with input from the community (instead of owned by members of the community) and the closest alternative platform was (and still is) a long way behind in functionality and general awesomeness.

But in the interests of the fantastic community and content I wanted to see continue, I got over myself! I arranged with Nick Swan, the original SharePoint Overflow mastermind that we look at moving the platform to Stack Exchange 2.0. After eventually being able to contact the very busy Stack Exchange team, things were put into motion and here we are (87% committed at time of writing).

So what’s going to make SharePoint Overflow 2.0 so exciting?

Our site started using a copy of how Stack Overflow functioned back in mid-late 2009. Now, if you’ve ever read the Stack Exchange team blog, you’ll know they’ve added many new features since then. Some of these will be great for us! Here are my picks.

We’ll be exposed to a greater audience

Stack Exchange sites are promoted across the network. You can see this in ads for questions on other sites, Twitter feeds, the listings of Stack Exchange sites, they’re everywhere! One of the great things is that a single login to the Stack Exchange network associates accounts across sites. This boils down to it being easy for people to come and join us.

We could be the keepers of all existing SharePoint questions from the trilogy sites

As a community in association with Stack Exchange, we may decide that SharePoint Overflow is where all SharePoint questions should live. That means many questions from across the trilogy sites will be migrated, as well as any new questions. It also gives those questions about SharePoint that don’t seem to quite “fit” in one of the existing trilogy sites a home (great explanation by Stuart Pegg). This should make us the largest SharePoint community Q&A site outside of MSDN and TechNet!

Note: “trilogy” here means the sites Stack Overflow (programming), Server Fault (systems administration), and Super User (computer enthusiasts).

We’ll have more encouragement to accept answers

Something that’s always been a problem in our site has been encouraging people to accept answers (and vote generally). Complete speculation from me is that this isn’t a nice experience or have any obvious benefits on MSDN/TechNet, which is the platform most of our users are previously familiar with.

Reason aside, users will have an “accept rate” shown underneath their reputation on questions they ask, just like on my Stack Overflow question here. This feature made a big difference when it was introduced on the trilogy sites! Sadly we just missed out on it with Stack Exchange 1.0.

We’ll have our own meta site to discuss how the site should be run

I’ve really felt a bit in the dark with how to administer the site, and haven’t wanted to clutter it up with a lot of meta questions. (We used the sharepoint-overflow tag for this.) With our own meta site (example), it will be much easier for us all to discuss the future and do the best thing in the interests of our community.

We’ll have several interesting possibilities of support

The Stack Exchange team really actually care about supporting communities and making the Internet a better place. For example, they’ve recently announced community conference sponsorships to help people share knowledge and experiences. If they can do that, I think we might at least be able to get some stickers?!

The future is bright

So that’s my feelings on the exciting future of our site! These are exciting times, so please, come and join us! Here’s how to spread the word. (As explained by Tom Resing we most need committers to have at least 200 reputation on other Stack Exchange sites.)

Finally, a very sincere thank you to the fantastic members of the community that have helped us become so successful (notably moderators Marc Anderson and Charlie Lee)!

Administrators! Stop before deploying that custom code!

Leave a reply

Even with no development knowledge, there’s a simple and quick tool that SharePoint administrators can run before deploying a solution package or web part to get some idea on whether it could cause instability your farm! It’s SPDisposeCheck and is particularly useful to keep an eye on the work done by a third party or even internally, with no developer knowledge whatsoever.

The tool was released by Microsoft in early 2009 to help developers check for memory leaks in their code. However there’s no reason why an administrator can’t do the same. Memory leaks can cause performance problems and general instability in your SharePoint farm. This tool tells you of any potential problems, and here’s how to use it:

Download SPDisposeCheck and install. By default this will copy SPDisposeCheck.exe to C:\Program Files\Microsoft\SharePoint Dispose Check.
Examine the deployment file you have been given. If this is a WSP file, rename its extension to CAB and extract all DLL files. SPDisposeCheck also works on EXE files if you’ve been asked to run a console application.
For each DLL or EXE, run SPDisposeCheck using the filename as a parameter. To be assured of no SharePoint memory leaks, check that the “Total Found” line is 0.

Here’s an example that shows a potential leak:

If the tool finds some issues then you should query this with the developers. However as the tool itself states, this doesn’t necessarily mean there is a leak! Unfortunately it can report false positives depending on how the code has been written. Regardless, make sure you have an assurance that the tool is run as part of their release process and any flagged issues have been checked. The tool will never miss a problem with a false negative.

It’s as simple as that. Be sure to add SPDisposeCheck to your admin toolkit and don’t let those developers get away with dodgy code!

Query Demo Web Part

Leave a reply

A question recently came up on Stack Overflow about querying data from multiple SharePoint lists and binding the results to a GridView control. I realised there were some types of SharePoint queries I hadn’t explored, and that it would be interesting to compare them and see how they work in a web part.

Hence, I created the SPQueryDemo web part! It tests and displays results from the following types of queries:

For loop
GetListItems from Lists web service
SPQuery for SPList objects
SPSiteDataQuery for cross-site list queries
CrossListQueryInfo for cached cross-site list queries
PortalSiteMapProvider for SharePoint Server publishing sites only

Download it from CodePlex.

I’ve also used this project to try out using user controls for output rather than the traditional dynamic creation of controls in a SharePoint web part. This has been attempted with an MVP-style pattern which I’d really appreciate any feedback on.

In the future I’d like to add more functionality, particularly for different query options and types of queries. There is also an annoying bug when changing the query type where the page needs to be refreshed before changes take affect. If anyone would like to help or just check out the code, please download the source and hack away! You can also contact me via this blog post or via Twitter.

When alerts don’t work ‘by design’

Leave a reply

I’ve just spent many fruitless hours trying to find a bug in my code that has been causing minor but visible pain for a number of users – and it was never even there. You would think after spending several years working with SharePoint I would know all of the ins-and-outs of alerts but not this one!

Scenario

“Require Check Out” is set to Yes (toggle the screenshot below in your mind, please!)
Alert created to only send when new items are added

Problem

User does not receive alerts on new items.

What’s happening?

When “Require Check Out” is enabled, alerts for a new document are only processed when it is checked in, and only the most recent alert event is kept. Here’s a simplified version of what SharePoint is doing behind the scenes when a user sets an alert for new items only:

Action	Alert-related behaviour	Response to user
User uploads a document	“New item” event registered	“Fill in properties and check in” page displays
User clicks “Check In”	“Changed item” event registered and alert functionality triggered – most recent event is processed, sending a “Changed item” alert (“New item” event is discarded)	Document checked in and user receives no alert

This is also an issue for users opting to receive alerts with the “All changes” or “Existing items are modified” options set. Their alerts will read the item has changed when actually it is new.

I asked about this on the SharePoint forums and received a good response from Lu Zou-MSFT confirming this behaviour. Unfortunately it’s unknown if this behaviour will change for SharePoint 2010.