Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.6K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 298 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Recomputing SIFT Tables
megawavez
Member Posts: 133
Hi,
I originally posted in the Attain forum, but we are using the 3.7 executables, so I'm reposting here. Is there anyway in the 3.7 or 5.0 executables to recompute the SIFT tables? I want to do some updates through SQL, but this will leave some of the SIFT tables out of sync.
I've found that disabling and reenabling the SIFT indexes does the job, but this will be cumbersome. Thanks,
Mega
I originally posted in the Attain forum, but we are using the 3.7 executables, so I'm reposting here. Is there anyway in the 3.7 or 5.0 executables to recompute the SIFT tables? I want to do some updates through SQL, but this will leave some of the SIFT tables out of sync.
I've found that disabling and reenabling the SIFT indexes does the job, but this will be cumbersome. Thanks,
Mega
0
Comments
1. Unless you are doing BULK inserts, standard inserts in SQL should update the SIFT tables. If you look in the Insert Trigger on any table with SIFT you will see that portion is executed on the SQL tables themselves.
2. Another option would be to consider doing a technical upgarde to the 5.1 executables. In that version of NAV, the SIFT tables aren't used. Instead they use index views.
3. Otherwise, in 3.7, if you go to file -> database -> tables -> (find the table you want) and click optimize, the SIFT index will be rebuilt.
btw: is it possible to just do a technical upgrade to 5.1 for performance reasons?
Thanks
Thomas
I believe, if you do decide to go down the technical upgrade route to 5.1 road, that it is especially important to do a back and restore into 5.1, rather than just a simple conversion of the database.
I think this may depend on the version of the source database. With a new database like 5.0 I see no issues with a straight conversion. I may be tempted to go the backup/restore route with an older database.
Ah... this explains it - I did a truncate on the table. Thanks for the help.
Mega
I'm just speculating, but since the 5.1 uses index views instead of doing inserts into a SIFT table, and since the insert code is on the SQL tables themselves, I would imagine that's the reason for doing a backup and restore - so the tables can be rebuilt with(out) the correct code.
Again, just speculating, but I thought that all a the "straight" conversion did, was update a database property. It didn't really change anything else on the server side. Does anyone know the answer to this?
I've been working with a client on a 3.60 to 5.0 upgrade for several months (also native to SQL). When SP1 came out we decided to do a technical upgrade. We simply converted the database and it appeared to make all the correct changes. We have been tetsing with this database for about 5 or 6 weeks.
We also tested going back. We were able to make a NAV backup of the SP1 database then restore it into an empty 5.0 database. The sift was properly re-created.