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:
The topic of data integrity is an important one. You should always make sure that your data is in a consistent state, particularly during modifications. To do this, you should use the built-in functionality of the DataSet class, which allows you to deal with cascading updates and deletes, manage constraints, and the rest.
There are two key classes in this part of the framework: UniqueConstarint and ForeignKeyConstarint. Both of them defines rules that must be applied to the data stored in the DataSet (as long as the EnforceConstaint property is set to true). Let’s start with the ForeignKeyConstraint, because it’s slightly more complex than the other one.
You set up a ForeignKeyConstraint like this:
ForeignKeyConstraint fkc = new ForeignKeyConstraint(parentColumn, childColumn);
After you have declared it, it behaves in the exact same manner as if it was set up in the data source. There are four actions which can take place when you delete the foreign key column, depending on how you set the DeleteRule property. Also, the UpdateRule can be set to the same values, which are:
Now this one seems to be a huge topic, but have no fear, we’ll overcome it. The “may include, but is not limited to” section says: update data by using stored procedures, update DataSets to data source, managing concurrency.
Updating data by using stored procedures is not the hardest task in our lives. Simply build a SqlCommand object, set the CommandType to StoredProcedure, and use parameters (always use parameterized SQL commands, because SQL injection attacks will haunt you in your dreams if you wouldn’t do so). I think this one is out.
To update DataSets (and all the related stuff) is a bit more complicated. You should use DataAdapters (or TableAdapters, strongly typed or not) to solve this issue. DataAdapters expose some properties related to updated data, such as UpdateCommand, or DeleteCommand and InsertCommand. If you remember what I wrote about the states of DataRows, you can easily put the pieces together. If not, here’s a brief refresher:
When you call the Update method of the DataAdapter, it will treat DataRows differently, based on their RowState property. On the ones marked Deleted, it will call the DeleteCommand. In a similar way, Modified rows will be processed by the UpdateCommand, and Added will be by the InsertCommand. Watch out of this, because there may be exam questions lurking out there on this topic.