Wednesday, March 26, 2008
#
Today I had a discussion about when to limit the number of attributes into Microsoft Dynamics CRM to gain with performances and I've observed that there's not always a clear idea on how SQL Server manages these things.
When you add a custom attribute on a CRM entity, Microsoft Dynamics CRM adds a new column on the corresponding table into the SQL Server database.
With SQL Server 2000, the maximum length of a table row was 8 KB. While this is still the physical maximum length of a page, SQL Server 2005 can move overflow varchar, nvarchar, varbinary, or sql_variant data to another page while maintaining a 24-byte pointer on the original data page, making it possible to store a row that contains more than 8 KB of data. To accommodate overflow in this way, each column in the row must have a maximum length of 8 KB. When the combined length of all the columns is greater than 8 KB, SQL Server will automatically move the largest column to an overflow page.
With the last Microsoft Dynamics CRM 4.0 the row size limit is bypassed because it supports only SQL Server 2005. However, remember that in order to have better performances, you should stay below the 8KB limit.
This little notes is obviously valid not only for CRM 4.0 but also for Microsoft Dynamics NAV and for every database tables in general. Don't spread too much with attributes...
Due to the increasing number of trackbacks spamming (last month was terrible!), I've disabled the trackback feature on my blog.
Unfortunately seems that also Akismet is vulnerable... 
Maybe a day I'll use something different, for example a CAPTCHA like this:
Some weeks ago I was invited to leave feedbacks on a survey published by Microsoft about the next version of the Workflow Designer. One of the coolest feature about the actual WF Designer is that you can rehost it inside any custom application (for example a Winform application) and you can enable your end users to edit processes or simply to to visualize and monitor the workflow state.
For my little experience I've done in these months on trying to rehost the WF Designer, I can say that it's not so easy as someone could imagine. However, despite the difficulties on doing this, the actual WF Designer is not always so "friendly" for the end user. I want to leave you here the ideas I had on my personal WF Designer Rehosting case because I think that they're common to many of you.
Basically, I'd like to have a custom application where to rehost the WF Designer in order to:
- Give the power to the end user to graphically monitor the WF state and flow (by viewing the WF diagram on the application).
- Give the power to the end user to have a set of custom activities that he can use to create his simple workflows via the application interface.
- Give the power to the end user to modify the actual running workflows simply via the application UI.
Obviously, I'd like that the end user that works with my application could be a person that doesn't know the WF platform, but that it can work with his workflows in a simple and intuitive way without advanced programming knowledges.
Is it possible to have something like that in the next WF Designer? I think it could be marvellous if Microsoft will provide something that permits us to give this power and this simplicity to the end users.
If this could be possible, I think that the WF platform will increase his power a lot... from a platform for the developers it could be adapted to be a framework directly for the end user.
Why not having a sample of this in the near future? Maybe a Winform or WPF application (or better, both 
).
We'll see what happens...