mibuso.com

Well, I was just getting frustrated that nobody was discussing the KB article the post was supposed to address, but you were apparently just as confused as I was after reading it.

You (and others) keep talking as if the SQLIndex and MaintainSQLIndex properties suddenly don’t work. I hope we agree that they both “work”, it is just the consequences of changing the SQL Index that is different due to the Dynamic Cursors. I am still customizing the SQL Index to optimize, so I disagree that we never should do it. We should just use more caution.

Really? Are you saying that specifying a cursor type, is like specifying an Index Hint to overrule SQL’s own logic? I have looked at MSDN and found this article http://msdn.microsoft.com/en-us/library/ms712466(VS.85).aspx This is new to me but seems like a good idea. I just fear it will require further specification before each FINDSET or similar cursor operation.


This is the case with almost all the KB articles about the run-time changes in NAV. Extremely frustrating.


I have heard from an MS supporter that they are changing back to Fast Forward cursors, but only partly. I have e-mailed him for clarification, but I haven’t got any response. I therefore hoped someone in here knew something.

I think you will find this is just for GUI requests as I mentioned in my post above.

Ok, I was told that is was "until a transaction had started". That didn't make any sense for me, but you might be right. I have only tried two builds after 27191, and they had so many errors I decided to stick with the rather old build. Now I'm just tring to decide if it is time to give it a go again...

@David:
That's why i supposed sqlindexes were not working 100% correctly...
http://blogs.msdn.com/nav_developer/archive/2009/04/10/beware-the-sql-index-property-on-nav-5-0-sp1.aspx

No this is the issue. These functions used to work, in earlier versions of Navision, but don't work with the newest versions.

!!!eheh, what a fool...maybe i have to read more carefully...then the article i posted before (http://blogs.msdn.com/nav/archive/2009/ ... -uses.aspx) doesn't say anything about the possibility to make SQLIndexes differents from the original nav index...ok, now i got it, thanks for the explanation

Why do you keep "blaming" the properties? The problem is not the properties - the problem is the cursors...

You misunderstand. I am saying these functions don't work, though maybe "are not usable anymore" or "do not serve the purpose they were originally intended for" or "USE WITH EXTREME CAUTION".

The reason they don't work is because Navision is forcing (or at least strongly suggesting) to SQL that it use Dynamic Cursors.



We are agreeing here trust me.

No worries then

Technically yes but if you look at it from a "cause and effect" point of view (Adding simple and selective SQLIndex causes faster queries) then you can't deny that this "doesn't work" anymore. The SQLIndex property is still there, and it does what it is supposed to do as far as setting the index on the SQL Server table object. However, it is now more likely to cause even further performance problems. To me that is a step backward.

We used to be able to significantly tune an entire database (which came down to tuning about 20-30 tables) in about 2-3 days. All we did was analyze the indexes, modify them (i.e. simplify them in most cases), and we had huge successes and gains in performance. Now you have to match indexes on SQL Server with the key on NAV, so if you have to make keys more selective, you have to add the key, find all the code that reference that key and modify that too. Anyone who'se ever done a field length increase knows how much time this takes.

It is not fair to the customers, especially to those who have invested in tuning their databases. We should have had the option, this should be a database setting, or even a table setting.

Yes, it seems we all agree.
If I should "defend" the usage of Dynamic Cursors, it would be someting like this:
"It improved the results in the Application Benchmark Toolkit in the Cronus DB!"
This is just useless for the partners in the real world, and is making me wonder if Microsoft finally is forcing customers with more than 80-100 users to AX by putting these handcuffs on NAV.