With the announcement of the .NET 4.0 exams, it seems a bit like a wrong career move not to aim for taking the web application development certificate for 4.0 instead of 3.5, since I have already been working with VS2010 for some time now.
Looking at the Skills Being Measured List it seems like a good idea to continue studying the MCTS Self-Paced Training Kit (Exam 70-562) with a sharp eye to the list of topics.
Hopefully I will be invited to take a beta exam when they come out in April.
I guess a good place to start looking into the ASP.NET 4.0 would be here
Here are some of my comments to the elements of What's new:
Showing posts with label 70-562. Show all posts
Showing posts with label 70-562. Show all posts
Thursday, 4 March 2010
Tuesday, 9 February 2010
ExecuteScalar doesn't return the return value
One thing to remember when making a stored procedure or just simple SQL, which should be executed thought a call of the ExecuteScalar method in .NET: that ExecuteScalar doesn't actually return the return value but the first column of the first row in the result set, or a null reference if no result is found!
Thursday, 7 January 2010
The skitzofrenic DataRow Versions.
The DataRow contains several different versions (DataRowVersion) of the data it contains and several different RowStates, and of top of that it can be in edit mode or not. This can be a bit complicated grasp, in the following I will try to explain to myself (and any other reader) how it works.
The RowState is a description of the rows connection to a DataTable and whether the data is changed.
The different DataRowVersion contains the different versions of the data, and can either be: Current, Original, Proposed or a pointer to one of the three (it is usually denoted as the Default).
And finally a DataRow can be in Edit Mode or not. A DataRow enters and exits this mode when BeginEdit and EndEdit is invoked respectively.
The lifetime of a DataRow can pass through these RowStates:
Strangely enough the DataRowVersions doesnt really have anything to do with the RowState, but whether the DataRow is in Edit Mode or not(or well in RowState Deleted.
Before an Edit the default data in the row is found in Current version. In edit mode the default data will be in the Proposed version, while the current version contains the unedited version.
After an Edit the Original version contains the data from before the edit, while the Current version contains the hmm... current version (in other words the Proposed version in Edit mode).
The RowState is a description of the rows connection to a DataTable and whether the data is changed.
The different DataRowVersion contains the different versions of the data, and can either be: Current, Original, Proposed or a pointer to one of the three (it is usually denoted as the Default).
And finally a DataRow can be in Edit Mode or not. A DataRow enters and exits this mode when BeginEdit and EndEdit is invoked respectively.
The lifetime of a DataRow can pass through these RowStates:
- Detatched: The DataRow is created but not attached to any DataTable.
- Added: The RowState goes to Added when it is added to a DataTable.
- Unchanged: If the
AcceptChangesmethod is invoked, the RowState becomes Unchanged. - Modified: If the data is modified the RowState becomes Modified, this is however not true if the current RowState is Added.
- Deleted: When the
Deletemethod is invoked.
Strangely enough the DataRowVersions doesnt really have anything to do with the RowState, but whether the DataRow is in Edit Mode or not(or well in RowState Deleted.
Before an Edit the default data in the row is found in Current version. In edit mode the default data will be in the Proposed version, while the current version contains the unedited version.
After an Edit the Original version contains the data from before the edit, while the Current version contains the hmm... current version (in other words the Proposed version in Edit mode).
Subscribe to:
Posts (Atom)