How much times we have the question on the forum to downgrade a DB after someone accidently opened a DB with a newer NAV version and upgraded the DB?
Lot’s of times.
Downgrading is not so easy and it can be slow.
I needed to do it some time ago (luckily NOT for production but just for some […]
Filed under: C/AL, NAVISION, PERFORMANCE, SQL | Make a Comment »
Do you remember the Clustered Index bug of 4.0SP1 (see also http://www.mibuso.com/dlinfo.asp?FileID=594)?
In short: 4.0SP1 forgot to set the index-property “Clustered” on the primary key (the default is that the primary key is clustered). The result is that the tables were heap-tables and that is (generally) bad for performance.
The fix was to put the key-property Clustered […]
Filed under: C/AL, NAVISION, PERFORMANCE, SQL | Make a Comment »
It is field 8725:”Signature” and it seems to be used in F8726:”Mobile Order Signature”.
Question: Why a post about this field?
Answer: Because it can (and sooner or later) will cause performance problems.
What happened?
A colleague calls me to tell a customer has performance problems open the sales order form. But not always.
I found out that when opening […]
Filed under: NAVISION, PERFORMANCE, SQL | Make a Comment »
I found out this virtual training and thought it could be of interest for SQL tuners.
http://www.vconferenceonline.com/shows/spring10/quest/register/multireg.asp
The bad thing is: it starts at 07:45 ET-time.
That means 13:45 CET. And it stops at 23:30!
Anyway, I am following it with the moka (to make italian coffee) nearby.
Filed under: PERFORMANCE, SQL | Make a Comment »
Maybe you ask: what title did he invent now? It has nothing to do with NAV or SQL
Oh, yes! It is about both!
Here it comes.
The crime scene: NAV2009 classic client with NAV Jobqueus that launches a job in a Webservice and goes on with other jobs (thanks to ara3n for his blog that helped me […]
Filed under: CLASSICCLIENT, NAS, NAVISION, PERFORMANCE, SQL, WebService | 3 Comments »
As we all (should) know, SQL is based on sets and NAV works iterative with records.
Sometimes it is possible to do set based programming also in NAV.
I just found an example in which we can speed up something thinking in sets (1 record is also a set!) instead of iterative. The beautiful thing is: it […]
Filed under: C/AL, NAVISION, NAVISION-DB, PERFORMANCE, SQL | 3 Comments »
I just wrote a new how-to how to work with record-variables and the responses made me test some things.
While testing the SQL-statements between GET,FINDFIRST, FIND(’=’) I noticed something VERY interesting!
In the OPTION of the select, I noticed (OPTIMIZE FOR UNKNOWN)!
Maybe you are asking why I am so exited about it?
Remember the problem with SQL2005 selecting […]
Filed under: NAVISION, PERFORMANCE, SQL | Make a Comment »
Lately I have very little time to write blogs or to be online in general. But I found some time anyway to write a new how-to. Took me over a month anyway to write it.
I have noticed too many times that a lot of people use record-variables in a completely wrong way.
The smaller errors just […]
Filed under: C/AL, NAVISION, NAVISION-DB, PERFORMANCE, SQL | 1 Comment »
To check
#users /#transactions
Multiple countries in 1 DB
#users>200 : attention
Large opportunities
Amount $
# transactions
# users
Competitors say: NAV is not scalable and for small customers
How to address challenges
1 or more instances (scale out)
Check #users/transactions
Check user profiles (light/medium/heavy users and which modules do they use)
Check (add-on) version : […]
Filed under: DirectionsEMEA2009, NAVISION, PERFORMANCE, SQL | Make a Comment »
I just noticed that ara3n made a blog-post about SQL2008 crunching (http://mibuso.com/blogs/ara3n/2009/02/17/sql-2008-compression-on-nav-database/) and I decided to add some information too. He did testing on DB-scale to see what happens to the DB. I did testing on some tables with enough records in it. I wanted to know how tables would be crunched with page-crunching or […]
Filed under: NAVISION, PERFORMANCE, SQL | 1 Comment »
Create a new blog and join in the fun!