Navision2.6 and SQL Server 2008

cpina

Navision2.6 can migrate to SQL Server 2008???

Thanks you

azerty74

I would upgrade towards 5.1 before using Sql 2008...
Since you're still working on a 2.6 (#-o) maybe a new implementation with a data migration would be cheaper ?

kriki

[Topic moved from Navision Financials forum to SQL General forum]

DenSter

I would wait until Microsoft comes out with an official word that SQL Server 2008 is supported. I know that some people have it working, but I'm always careful about these things, I think it's better to wait until the official word comes out (or get a status and perhaps an unofficial patch through MSFT support)

ara3n

Here is the KB that will support 2008

http://blogs.msdn.com/ukdynsupport/arch ... 0-sp1.aspx

kriki

ara3n wrote:

Here is the KB that will support 2008

http://blogs.msdn.com/ukdynsupport/arch ... 0-sp1.aspx

It is supported for WINDOWS2008 and not for SQL2008!

DenSter

A reference to a KB article in someone's blog in the UK is hardly an official release.

ara3n

kriki wrote:

ara3n wrote:

Here is the KB that will support 2008

http://blogs.msdn.com/ukdynsupport/arch ... 0-sp1.aspx

It is supported for WINDOWS2008 and not for SQL2008!

My mistake.

Marije_Brummel

I would wait as well.

We have some 2.01 and 2.6 databases working like a charm on SQL2005. They are much easier to tune because of the less complex data structure.

Some customers have a perfect working 2.6 database. If upgrading has no benefits there really is no need.

SQL2008 works. We are using it for a while now withous any issues. We are not a large company so we do not have performance issues.

So far, the only benefit I found in SQL2008 is the T-SQL editor with autocomplete. :-s

My advise is always to wait for someone else to be first with the issues.

kriki

Mark Brummel wrote:

So far, the only benefit I found in SQL2008 is the T-SQL editor with autocomplete. :-s

Another one : native crunching of backups! I tried it out on a Cronus-DB in a virtual Machine. It was a lot faster.

And another one (at least once we have table-property for in NAV): it is possible to crunch the data in the tables, making them smaller, faster to read and faster to write, but costing extra CPU-time to do it (with the current server hardware, this is hardly a problem). I didn't test it out, but I read some positive things on some SQL-forums/blogs.

DenSter

I blogged about that months ago:
http://dynamicsuser.net/blogs/denster/a ... -wave.aspx

azerty74

Something I also find interesting is the possibility to do Change Tracking. This could be a great extention/replacement of the Dynamics NAV Change Log. But I don't have any experience with it, and performance wise it is supposed not to have a big impact, and with these kind of things, it's better to first test them extensively...

ara3n

One issue with change management tracking in sql 2k8 is that you cannot make any structural changes to the tables. And if you have to, you have to disable it for the table and make the changes and enable it again. So you loose all the history.