SQL tuning

illug
Member Posts: 21
Hi ...
I want to start experimenting with using the SQLIndex property. But first I would like to ask if anyone knew what the results would be if for a key in Navision MaintainSQLIndex would be False but MaintainSIFTIndex would be true?
I want to start experimenting with using the SQLIndex property. But first I would like to ask if anyone knew what the results would be if for a key in Navision MaintainSQLIndex would be False but MaintainSIFTIndex would be true?
0
Comments
-
Using copy paste, I could pre-post for you all the replies that you are about to get for this topic
\:D/
And all though I don't know the exact answer, I am curious as to how this would be possible? I guess SQL would create the SIFT table, but would not index it?David Singleton0 -
Why don't you test this?
I use this sometimes to eliminate dirty fields like variant code from the sift levels without chaning the NAV Key.
David,
The SQL Index and SIFT Table have nothing to do with each other.
The SQL index is just an index on the existing table, while the SIFT Table is a new table with it's own (2) indexes.
So the answer is YES, you can have a SIFT table without turning on the SQL Index.0 -
illug wrote:if anyone knew what the results would be if for a key in Navision MaintainSQLIndex would be False but MaintainSIFTIndex would be true?0
-
Mark Brummel wrote:...
The SQL index is just an index on the existing table, while the SIFT Table is a new table with it's own (2) indexes.
So the answer is YES, you can have a SIFT table without turning on the SQL Index.
Yes that seems to make sense, thanks.David Singleton0 -
Thank you for your replies.
I´ve just migrated from Native to SQL 2005 and probably have a lot of tuning to do. What I am thinking about (and the reason for my original question) doing has to do with this key in the Item Ledger Entry:
Source Type,Source No.,Item No.,Variant Code,Posting Date
Some users are using this to see item sales for specific customers. I thought it might make sense not to maintain it in SQL, and create a new key Source No.,Item No. that would be used in stead.0 -
illug wrote:Thank you for your replies.
I´ve just migrated from Native to SQL 2005 and probably have a lot of tuning to do. What I am thinking about (and the reason for my original question) doing has to do with this key in the Item Ledger Entry:
Source Type,Source No.,Item No.,Variant Code,Posting Date
Some users are using this to see item sales for specific customers. I thought it might make sense not to maintain it in SQL, and create a new key Source No.,Item No. that would be used in stead.
This way you don't need to create a new key in Navision.Regards,Alain Krikilion
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!0 -
[Topic moved from Navision forum to SQL Performance forum]Regards,Alain Krikilion
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions