Today, I’ve passed the exam 70-561, ADO.NET Application Development, which completes my second MCTS certification. I must confess that this one was the most difficult so far, and took the most time to fulfill. I expected simple questions, but found monstrous ones, and found myself trying to figure out a single question for minutes.
However, I’ve only studied for a week (and have two years of experience building data-driven apps), so I might have been lucky to pass. As you could read it in the syllabus, the exam focused mostly on data modifying and querying, with a large percentage of synchronization-related questions. The Training Kit was useful for preparing, but you definitely need to dig through some MSDN articles, because there are serious white spots in the book.
All in all, the exam was though, and you should prepare for it more than a week, it won’t hurt your performance on it!
The next goal is the WCF exam, 70-503. I’ll start publishing posts as I review the topics, but first I’ll need to complete my university exams (you know, sociology), so there will be a slight delay, but I’ll take that one before the second shot offer expires (30th June).
And finally, some bad news: there won’t be any posts published about the Entity Framework. It’s a very useful feature, but I’m tired of trying to understand it wholly, sorry.
I must apologize, but the two objectives related to LINQ will not get published on this blog. These objectives are: Query data sources by using LINQ, and Transform data by using LINQ. The reason is very simple: LINQ is something huge, and there are so many information about it out there, thanks for the hype, that I really don’t want to bother with it.
The other reason is that I’m not seeing myself as someone who can teach other people about LINQ. I have two many white spots about it. Maybe in the close future (I’ve started reading Pro Linq from Joseph Ratz, but lack the time to get to the end of it) I’ll publish something about it, but for now, I’m not prepared enough.
When you are working with the Sync Framework (a topic of a coming soon post), you will inevitably run into issues related to data modified both on the client and the server, more clearly: update conflicts. There are five types of update conflicts, defined in the ConflictType enumeration:
- ClientInsertServerInsert: both the client and the server insert a row with the same primary key.
- ClientUpdateServerUpdate: the client and server changes the same row (this is the most common conflict type).
- ClientUpdateServerDelete: the client updates a row, which have been deleted on the server earlier.
- ClientDeleteServerUpdate: the client deletes a row, which have been updated on the server.
- ErrorsOccurred: an error prevents the change from being applied.
To detect errors during synchronization, you should use the ApplyChangeFailed event of your provider class. This returns an ApplyChangeFailedEventArgs object, which exposes information about the rows in conflict, the error, and lets you specify the Action to take. The Action can be a member of the ApplyAction enumeration, which defines the following set of them:
There might be times when you’d wish to receive a notification about a change in the returned results of a command. In these times, you would use the SqlDependency class, living in System.Data.SqlClient. For it to work, you should enable SQL Service Broker for your database, because raising notifications requires you to do so.
As I stated, SqlDependency can be used to query whether or not a given SqlCommand’s result changed (or any related changes have occurred in the database, such as a failure). There are two ways to get notified about changes: query the HasChanges property of the current SqlDependency instance, which is a Boolean value informing you about changes in the database. The other, more robust approach is to use the OnChange event of it. It returns an instance of SqlNotificationEventArgs, which exposes the following properties:
- Info: gets the reason of the notification.
- Source: gets the source of the notification.
- Type: the SqlNotificationType of the notification. Can be Change, Subscribe or Unknown.
Now that you know the basics, here’s an example:
In this post, we’ll examine two ways of how to cache data in a .NET Framework application. For ASP.NET web apps, we’ll use SqlCacheDependency, and for desktop applications, we’ll consider using the Local Data Cache.
When dealing with ASP.NET applications, you have multiple choices to cache data, by using one of the state management techniques (I have written multiple posts about them, so search for them), but for now, we’ll consider using the Cache class. Before you’d write any data caching code, you should start in the web.config, as usual. Take a look at the following block:
<sqlCacheDependency pollTime=”1000” enabled=”true”>
<add connectionStringName=”aString” name=”databasename”/>
After this, you should place something similar to your data access class: