While using Visual Studio LightSwitch with an external database, I came across a minor issue when creating a new entity.
I’m using the AdventureWorks Light database in my exploration. Most of the tables contain a field called rowguid.
The problem I encountered is how to initialize a property of type Guid when adding a new record.
For example, when you create a Customer entity using the SalesLT.Customer table in the AdventureWorks Light database, the Customer entity appears in the designer as follows:
I added a SearchCustomer screen and added an Add… button in the Command Bar.
When I run the app and click Add… button in the Customer screen, LightSwitch creates an empty GUID in the rowguid field:
The behavior I want is to automatically create a new Guid.
As a side bar conversation, you can argue the need to display this field. I believe in most cases you would want this field hidden. Only in a few cases, such as some type of management screen, would you want the Guid which identifies this row uniquely to be shown.
In any case, I don’t want to require the user to enter data in this field or for the field to be initialized to 0 for each new record.
Auto generating the Guid is accomplished by adding code in the entity’s Created method.
The first step is to have LightSwitch generate code that’s called when it creates a new Customer entity. Open the Customer Entity in the designer. Click Write Code in the main menu, then click Customer_Created in the drop down menu.
Next, add code to initialize the Customer’s rowguid property.
Now when you add a new customer record, the rowguid is initialized:
Pingback: Tweets that mention How to Initialize an Entity’s Property in LightSwitch | Dan Moyer's Blog -- Topsy.com
Pingback: Dew Drop – January 17, 2011 | Alvin Ashcraft's Morning Dew
Hi Dan;
I’ve got a quick question to ask you. looking at the AdventureWorks database, I see every table has the rowquid and modifieddate fields. Can you tell me what are these for? And how/if LS even uses them for?
Thanks!
Ben,
I don’t know why the rowguid and modifieddate fields are in the AdventureWorks database.
I can speculate how they might be used in an application based on how I’ve seen fields like these used in other business applications.
The rowguid field provides a mechanism to provide unique identity of a row to a specific database. I’ve seen production uses where the primary key of the table is not an int but a GUID value. Using a random GUID (a non-sequentially generated GUID) can impact database performance because the SQL indexing engine requires a full row scan when looking up a table– unlike a sequential INT key, or a sequential GUID key, which can be broken into a binary tree.
Consider you have two databases that you want to sync data between.
For example, one database may be used for testing / development, and the other database used for production.
Or consider you have a database on a local device which is capturing information and you want to periodically transfer — upload– the data to another database which has the same schema.
Because the rowguid provides unique identity of a row, you can be sure you have copied a row of data from a ‘source’ database to a ‘destination’ database when you do a sync operation from the ‘source’ to the ‘destination’
Because there’s nothing unique about a INT between two databases, it’s difficult to ‘sync’ data between two databases if all you have to go on is the integer primary key.
ModifiedDate field– I’ve seen usage of this field in databases used for business applications. I also noticed there’s a password hash table too. If you want to know the last time a row was updated, and which user updated the row, the data in the modifieddate and user’s password hash can provide that. It’s not a full audit record, like a source control system of allowing you to determine what has changed and how many times the row has changed. Just “the row has changed by user X on Date Y”
These fields are just fields like “FirstName” to LightSwitch. It depends on the application you’re developing with LightSwitch– the business rules of the application– of whether these fields have any use.
Because I see fields like rowguid and modifieddate in other applications– which I find the AdventureWorks schema more closely approaches than many of the demos in the videos or used in other blogs– I thought it would be useful to demonstrate how to initialize those fields in a LS application.
Dan
Dan, excellent points;
I see your valid point on using GUID for the sync purpose. Many years ago, I actually had to invent my own “unique” field, so I could compare two rows from two databases (as you pointed out, the INT were different) and I had created a secondary index based on this unique field, in order to find them. So, I can see the guid use here. I wonder if that’s what AdventureWorks uses it for.
On the Modified, I thought they might be either using for row concurrency or log of “last changed”. I had done so before by also saving the user who changed them.
I appreciate your feedback and hope to see you on LS forum;
Take care and thank you again.
..Ben