Linked SQL View Performance

tiki
Member Posts: 16
Hello,
We have a database that has a number of companies (30 - 40+), and there is a SQL view that unions all the companies together so that certain records can be displayed across companies. This view has 18,668 records and runs in under a second in SSMS. However, in NAV, the page for this is VERY slow and there is no extra logic to cause any slowdown (i.e. filters, etc.).
Has anyone seen slow performance in linked SQL views?
We have a database that has a number of companies (30 - 40+), and there is a SQL view that unions all the companies together so that certain records can be displayed across companies. This view has 18,668 records and runs in under a second in SSMS. However, in NAV, the page for this is VERY slow and there is no extra logic to cause any slowdown (i.e. filters, etc.).
Has anyone seen slow performance in linked SQL views?
0
Comments
-
Use of SQL profiler might give you a precise answer to how the server is queried when you use SMSS and what NAV does (wrong) when it quiries the server.Best regards / Venlig hilsen
Johannes Sebastian
MB7-840,MB7-8410 -
Thanks - that was my next step, so I'll look into it and post back if I find anything useful.0
-
I have seen this too in some case. I didn't find really a problem, but I think it is because the NAV client is slow (I don't know why) to receive the info.
If I used the same view and queried it using ADO, it was a lot faster.Regards,Alain Krikilion
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!0 -
Hi kriki, how would you translate that to the results on a page, etc.? Did you fill a recordset and then populate a temp table?0
-
We had similar issues with a fairly complex View which was fast when executed through management studio, but very slow on nav side. I then recognized that when you use client monitor you see that the sql command used to gather the records was a select top 1, which caused the view code to execute every once the next record was retrieved. This was a very bad situation since the view was so complex ant the minimum execution time was nearly the same as the maximum time (so if you do top 1 or select * would end in the nearly the same time). Therefore we needed to change things a bit. What we did, was instead of using the view directly, we use a stored procedure to transfer the view results in a Nav Table. Then we just use this table for processing the results.0
-
With that particular case, I used ADO to get the fields I needed in put them in a temptable and showed that temptable.
Another way is what deV.ch did: run a stored procedure that fills up a NAV table. Also that system I have used.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