In MSDN forums I came across a post addressing an issue I have also faced. Auditing fields can cause concurrency issues in LightSwitch (not exclusively).

In general basic auditing includes keeping track of when an entity was created/modified and by whom. I say basic auditing because auditing is in general much more than this.

Anyhow, this basic auditing mechanism is very widely implemented (it’s a way for developers to be able to easily find a user to blame for their own bugs :-p), so let’s see what this can cause and why in LightSwitch.

In the aforementioned post but also in this one, I have clearly stated that IMHO the best way to handle concurrency issues is using RIA Services. If you don’t, read what follows.

Normally in any application, updating the fields that implement Audit tracking would be a task completed in the business layer (or even Data layer in some cases and this could go as deep as a database trigger). So in LightSwitch the first place one would look into to put this logic would be EntityName_Inserting and EntityName_Updating  partial methods that run on the server. Which is right, but causes concurrency issues, since after saving the client instance of the entity is not updated by the changes made at the server and as soon as you try to save again this will cause concurrency error.

So, what can you do, apart from refreshing after every save which is not very appealing? Update at the client. Not appealing either but at least it can be done elegantly:

Let’s say all entities to implement auditing have 4 fields:

DateCreated CreatedBy DateModified ModifiedBy Add to the Common project a new interface called IAuditable like below:

 

namespace LightSwitchApplication{...

In this article we will create a simple chat application. If different users are using the same LightSwitch application, they will be able to chat with each other.



...

If you have installed CLASS Extensions you know that there are two different controls that are used to handle Color business type. The ColorPicker and the ColorViewer. If you have read the previous post of the series you know that behind the scenes, each one of these controls is a wrapper for 2 other controls. The ColorPicker is for editing whereas ColorViewer is used for viewing only. The reason of exposing 2 different controls was that I didn’t manage to correctly retrieve the information about the content being read-only and changing dynamically the behavior of the controls.

If you browse the code you will see in _Load and other places (be kind, I was desperate) the attempt to bind to IsReadOnly property of the DataContext.

What I wanted to achieve was to...

Sometimes we are faced with the need to read data from a .csv (comma separated value) or Excel file. One option is to import the data, but this can turn out to be more trouble than any benefit if the file changes frequently.

Using WCF RIA Services allows the option to place the .csv or Excel file on the server hard drive and have LightSwitch access the data directly. When the file changes, simply...