Posted on May 22nd, 2013 by kriki
Ever tried to shrink your transaction log and it doesn’t shrink?
(VERY IMPORTANT: Generally it is NOT a good idea to shrink the logfiles, but because it is NOT a production server and I need space instead of performance, it is a good idea to shrink the logfiles [oh, and I also have simple recovery model]).
First, […]
Filed under: SQL | Make a Comment »
Posted on April 16th, 2013 by kriki
I just read this article : Windows Azure: General Availability of Infrastructure as a Service (IaaS).
You can also sign up for a free trial.
And for MVP’s, with your MSDN, you can have a VM with 2 CPU’s permanently on-line.
I have one since July 2012 and use it for testing and I am very happy with it!
What […]
Filed under: AZURE, SQL, Virtualization, WINDOWS | Make a Comment »
Posted on March 13th, 2013 by kriki
Today I had a problem with a table that has around 5 million records. The table has as primary key “Header No.”,”Transaction No.”.
In the table is a field “Order No.” that at the moment is blank for all records.
I also had an index on that field, because I will need to search for it. I […]
Filed under: C/AL, NAV, PERFORMANCE, SQL, Uncategorized | 2 Comments »
Posted on February 26th, 2013 by kriki
I just read this post: http://mibuso.com/blogs/zenandtheartofcsidedevelopment/2013/02/22/consuming-nav-web-services-using-powershell/.
And I wondered if it was so easy as is looked. So I tried it out and indeed: It was so easy.
Now, I need something a little more complicated: I want to be able to send a parameter (I only need 1!) into the function. And I want to put […]
Filed under: C/AL, NAV, Powershell, SQL, WebService | 3 Comments »
Posted on March 5th, 2012 by kriki
Someone remembers I wrote about too many VLF in the transactionlog (http://mibuso.com/blogs/kriki/2008/12/23/some-tips-tricks-for-the-transaction-log/ ) and how to fix it?
Well, I just found a blogpost, stating that also the contrary can create performance problems.
Basically : if your VLF is too large, it takes too long before SQL Server can clear it and it takes too long to […]
Filed under: PERFORMANCE, SQL | Make a Comment »
Posted on January 25th, 2012 by kriki
Now that the native database is destined to disappear, it is more than ever time to migrate your database to SQL Server.
Most migrations have some problems with dates.
If you have dates in your system before 1753/01/01 [rambling]Of all date-representations, I prefer the year/month/day because it is the most logical. After all, we write hundred and […]
Filed under: C/AL, NAV, NAVISION, NAVISION-DB, SQL | 1 Comment »
Posted on March 22nd, 2011 by kriki
Before all : do you want first the good news or first the bad news?
If you want first the bad news, read the last part of this post first and then continue with the rest.
If you want first the good news, continue reading.
Filed under: NAVISION, SQL | Make a Comment »
Posted on January 25th, 2011 by kriki
If you need to do something that smells like administrating NAV and you have little experience, this book is a very good start. Instead of searching through (and inside) all the pdf’s on the installation CD or googling/binging/yahooing blogs/white papers/articles all over the internet, you have all the basic information TOGETHER(!) in 1 book!
It won’t […]
Filed under: CLASSICCLIENT, NAS, NAVISION, NAVISION-DB, PERFORMANCE, RTC, SQL, Virtualization, WebService | Make a Comment »
Posted on December 16th, 2010 by kriki
It took some time to finish the book, but I really have little time to read lately.
After reading the book, I am still as far as before reading it about be able to cook
But at least I did learn some other things!
For the C/AL beginners (after reading the w1w1adg.pdf !) it gives some […]
Filed under: C/AL, CLASSICCLIENT, NAVISION, RTC, SQL, VisualStudio, WebService | Make a Comment »
Posted on November 14th, 2010 by kriki
NEVER COMPRESS A DATABASE-FILE!
Well, I didn’t! I just virtually restored the database.
Eh? What?
Time for some explanation:
I have a customer that has a database of about 50 GB of data. And all the files are about 60GB.
The native compressed SQL backup (they use SQL 2008 Enterprise) is about 8GB. No data or page compression is used.
As […]
Filed under: SQL, Virtualization | Make a Comment »