The way Dynamics NAV manages SIFTs in version 5.0 SP1 is a radical step forward from previous versions. Dynamics NAV is now leveraging the power of native SQL Server functionality for this important feature. Prior to SP1, ever since Dynamics NAV was first ported to SQL Server, each SIFT index was implemented as a separate SQL Server table which had to be updated by a standard SQL Server trigger every time the base data table was changed. Building just a few SIFT indexes could slow certain Dynamics NAV operations significantly and many partners have had to become quite adept at SIFT performance tweaking.
All of this is considerably simplified in Dynamics NAV 5.0 SP1. SIFT tables are a thing of the past, SIFT triggers are no more. SIFT indexes are now implemented as “Indexed Views” which are a powerful feature of the SQL Server database engine. When you update a Dynamics NAV table which includes one or more SIFT indexes, SQL Server’s Indexed View(s) will automatically take care of maintaining the SIFT totals.
A SQL Indexed View is a materialised view which is most often used to keep aggregated totals based on a related SQL Server table. As Indexed Views are an integral part of the database engine they can maintain SIFT totals more efficiently than a structure involving custom TSQL triggers and separate tables. As a bonus, we will never have to worry about “zero SIFT records” ever again!
Part of this change means that you can no longer specify SIFT levels as all key columns are now included in each SIFT index. The “SIFTLevels” column (i.e. SIFTLevelsToMaintain property) has been removed from the Key maintenance window in Dynamics NAV 5.0 SP1.
This change, along with other performance enhancements in Dynamics NAV 5.0 SP1 (e.g. batching repeated inserts for the database into a single “Bulk Insert” operation), have delivered very significant improvements in the speed of certain typical Dynamics NAV operations.
Comments
There are different conditions to fullfill that indexed views work properly.
Thanks.
Ray
That said, I don't know a lot about SQL Indexes (yet) - if updates to the underlying table update the Index you've created, it's possible? Hopefully someone with deeper knowledge can give you an answer. You might have to give a bit more of a "For example" to get something more concrete, though.
CEO, Spare Brained Ideas, Göteborg, Sweden
New (April 2021) Getting Started with Microsoft Dynamics 365 Business Central Book Available: "Your First 20 Hours with Business Central"
http://msdn.microsoft.com/en-us/library/ms191432.aspx
After the clustered index is created, any connection that tries to modify the base data for the view must also have the same option settings required to create the index. SQL Server generates an error and rolls back any INSERT, UPDATE, or DELETE statement that will affect the result set of the view if the connection executing the statement does not have the correct option settings.
I have used regular views for simplifying reporting and list forms (read only) and with well peforming views they work well.
http://mibuso.com/blogs/davidmachanick/
As stated in the comparison of SQL Server 2005 only the Enterprise Edition of the server could use them for matching.
So do I have to use the Enterprise Edition if I want to use NAV 5.0 SP1?
http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx
Thanks for your advice.
http://blogs.msdn.com/microsoft_dynamics_nav_sustained_engineering/archive/2008/05/14/index-view-matching-dynamics-nav-5-0-sp1.aspx
Actually, I had a blog-peace ready for some time now ... . Didn't know about the UK blog, apparently . So I decided just to post it like it was .
You can find it here and here.
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog