Saying Farewell to the Native Database

Saying Farewell to the Native Database

  • Comments 14
I've met many people who imagine that everyone who works at Microsoft must be of a single mind, with one goal - much like a hive mentality. Nothing could be further from the truth. We are an organization of individuals, often passionate about our beliefs and very emotionally invested in the work that we do. We're very proud of our successes and we want to learn from our failures. We're very human. And as such, when I was asked to work with a team that would decouple the NAV product from our native database, it was with an element of sadness that I agreed. I can also admit that I wanted to do the job because, like many of you, I've worked with this product for over a decade and I wanted this one to happen by someone who understood what we were saying farewell to.    

You shouldn't be burdened with the technical details about decoupling the files from our build system, generating the lists of extra dlls that we no longer need to install, or reviewing documentation that has references to the database format. When we are about to commit a huge change like this to our internal systems, we send an email to all team members informing them of an impending ‘Breaking Change' and to give teams a last chance to speak up about the impact this will have in their work cycles. There were almost no issues raised but I did receive a large number of comments from team members along the lines of "are you sure we want to take this away," "aren't we giving up the NAV simplicity," and "this is sad."  And a part of me agreed.

But it's not really sad. The day we committed this change was a bit like the last day of High School. We've all had a fabulous time but our future is ahead.

It's not sad because the original goal of Navision was not to become a best of breed database product - we wanted to build business applications. We happened to build a very clever little database at the same time but it was never the goal to have the database as the reason that people buy NAV.

It's not sad because now we focus on SQL Server and we can ensure that SQL is the platform we do our enhancements on. And aim to improve performance on. And benchmark on.

We can spare our Quality Assurance (Test) organization the pain of testing on a legacy platform and double our efforts into the SQL stack. We can spare our developers from maintaining data connections for two different platforms and spare ourselves the discussion about how to take advantage of SQL features without impacting the way the native database is used. 

I'm looking forward to everything we can now do and I hope you will join us too.

-Stuart Glasson

For more information about the Statement of Direction for Microsoft Dynamics NAV where we talk about ending support for the native NAV database, see this blog post.

Leave a Comment
  • Please add 4 and 7 and type the answer here:
  • Post
  • I know the personal feeling of letting of of something you've worked for a long time, but surprised it took this long to finally ending classic db.

    In the last 8 years I've not implemented one classic system out of about 30-50 implementations.

    I hope that in future we can utilize the power of sql server much more than we have currently.

  • I don't see any reasons on further development on NAV, everything in NAV is an example on what should NOT be done, database structure the first.

  • I can assure you that also partners will have difficulties to let this go.  The native database wasn't only a "smart little database system", but much more.  It was "simplicity" in all it's forms.  Company-backup ... let's try that in SQL ;°) ... .

    But on the other hand ... I'm sure we won't loose that simplicity, so me as well am looking forward to the exciting future :-).

    Great article, Stuart!

  • Stop supporting the native database is a stupid decision.  All your arguments are internal MS arguments Stuart.  What about customers ?   I know MS does not have direct customers, so all of this is very easy to say.  There are thousands of companies out there working with NAV and are very happy with it. Especially the typical NAV characteristics.   They are forced to the SQL database without gaining any benefits from it. On the contrary, they need more expensive hardware, spending more maintenance costs and using the same product on a less stable database.  Another example of MS bringing a successor of a product on the market which has less quality.  Do not mention the new RTC, that is really a crap product. You probably have some nostalgic “high school” feelings with that to Stuart.

  • A suprising number of Nav installations are in the sector of less than 20 users. These sites do not have the skills to admin a Microsoft SQL database or would be willing to carry the cost of the class machine one ideally need to run SQL server on, leave alone a separate application server machine.

    The reallity of impact has not filtered down to the smaller size clients yet. In fact Microsoft partners would be careful to let it out too loud to the smaller clients. What was the value again of market share that Microsoft acquired when acquiring Navision?

    I dare say, we have not heard the last word on this yet.

    It is great to know we have an architecture that can penetrate bigger bussiness better. Cutting off the smaller implementations? That is yet to be seen. What is the rate of new customer adds in the smaller size businesses and in larger businesses, and what is our experience of where Microsoft place more weight? Bigger sites or more customer adds? Something to think about.

  • Hm, I don't understand this fuss. It never has been a secret than FDB will vanish, since MS took over NAVISION A/S in 2001. We all knew it, it was just a matter of time, enough time to prepare customers (and partners) for the move.

    SQL Server IS the right choice (IMHO!). Now, the NAV application is a compromise, neither running perfect with FDB nor with SQL. Once FDB is gone, there's no more reason for such a compromise, the NAV application could be 100% optimized for SQL, taking full advantage of all the SQL benefits - I'd say: NAV, welcome to the 21st century!

    Also small companies could run their system on SQL Server for a reasonable price, e.g. using workgroup edition etc.. Especially small companies can purchase SQL Server licenses for a decent price with "NAV Runtime License" - much cheaper than with standard licensing.

    Of course, SQL Server - even a small one - requires more attention than C/SIDE, but actually we are not talking about "rocket science" here - every IT "affiliate" could learn to administer SQL easily.

    The problem is, that way too many Dynamics partners are still sort of afraid of SQL, not seeing all the advantages they could provide their customers.

    So from my point: Bye, bye FDB!

  • Fully agree with Marius's comment. Stryk's comment that it has never been a secret that FDB would disappear is formally not true. Only until the last statement of directions this is formally announced. Back in those days NAV was running on SQL very poor. But that is not the point. The point is: is this in the best interest of the customer. In alle cases, small, large, laggards, innovative. The beauty of NAV as it is today is scalability and simplicity.

    The vast majority of companies that I know of are running on FDB. Stryk's statement that NAV is not running perfect on FDB is not experience. It runs perfect on FDB, unlike SQL. Although that has been improved dramatically over the last couple of years.

    The NAV platform offers a perfect scalable platform for:

    - small companies on FDB.

    - Innovative companies who want to make use of other MS products integrated with NAV on SQL server.

    - Large companies which are using SQL server for both innovation and scalability. I know of implementations of upto 1000 users on one database/ one company. Performance and stability is nowadays excellent.

    If you look at the NAV platform as I describe above, quitting FDB is no improvement at all.

    The Role Tailored client is even worse. There is no company that I know of that asked for such a UI. NAV users that I know of want to expand their NAV business application by adding mobile solutions, internet solutions, digitalizing documents, that kind of things.

    That is where they want to invest dollars in. Not a replacement of the UI doing basically the same and will result in a very expensive re-implementation.

    The MS NAV team should listen to the market more carefully.

  • The future is SQL. That is the reason why the Navision-company back in 1997 introduced Navision Financials on MS SQL!

    Now 13 years later this work has succeeded and therefore it is not necessary to use the native database.

    We also need a new client. This has been started now with the RTC!

    And in 2-3 years nobody will miss the old one. If you don't agree then try to put new users in front of the RTC and the Classic. And ask them to create a new sales order. Which client will be first? (Try ask your wife or girlfriend maybe ;-))

    If you live in the past you will never get ahead...

  • The benefit for the customers should be the central goal and topic.

    My customers are mostly small companies (typical between 5 and 20 users). You remember "Navision for small companies" ?

    And the actual pricing of Nav is very fine  for small companies ...

    Database:

    My Customers ask me, why they should leave a stable running, free, quick and administration-free database ? To get what ? More hardware costs, costs for new database, more administration and - if I look into Knowledge Base - more errors.

    RTC:

    In smaller companies "everybody does everything", therefore a Role Taylored Client maskes not so much sense.

    If we would realize menu structures in Navision like they were in "Entrepreneur", the user experience would be much better and input of a sales order would be much quicker ...

    Modern / future / ... :

    - A three-tier architecture can also be realized with the classic database.

    - Working together with other Microsoft programs like Office, Sharepoint, ... is

    also possible and extendable.

    - Other things like .NET-Connection and managed code are not a question of the datbase, but of the "Second Tier".

    My oppinion:

    Classic database should be used for small companies even in the future. If they grow or for bigger companies SQL-Sever is the better solution.

  • Hi

    Please read Stuart's post again.

    Stuart explains in geat details the arguments behind this change. It will just make NAV more expensive supporting two DB's.  

    It just give a huge cost overhead with two db systems and i prone to errors.

    It's a lot more simpel to develop to only one system.

  • Stuart:

    Thanks for the post!  It's great to hear about heritage and the opinions of what has been built upon in the past.  The end result is something that all of us should strive for and _communicate to Microsoft_ in order to effectively create a solution that every customer is satisfied to use.

    A couple of the comments in this blog posting aren't even worthy of a reply from anyone - ask 10 different developers a way to solve something and you'll come up with 100 solutions to the problem.

    The native database had it's place.  It performed well, scaled to 10 to 20 users without any real issues, and had a minimal footprint.  For the era that it existed in - it worked wonderfully.

    But, as times change, so do requirements and needs of businesses.  To state that the native database should be supported is like saying that SQL Server 6.5 should be used in a business because it's "faster" or "easier to manage".  Both statements are in fact "opinions" of people that have less experience managing an unknown database architecture because they do not have any experience with the platform - which is why partners panic when they hear this...the true end result is because it hurts their bottom line because they are looking so narrowly.

    I have many implementations that run off of SQL Server 2000+ that run without a single issue - many of them 5 to 20 users.  They don't need additional IT staff or extended knowledge - in fact they actually like SQL Server because of the DBMS features (i.e log shipping, online backups, native ODBC access without external components) that just make it easy to use with other applications.

    The native database, on the other hand, is not maintained or developed by DBMS engineers.  There's quite the difference between a DBMS that is built to allow a mixture of extended functionality vs. that of a database that is for specific functionality.  SQL Server is still _our_ database management engine platform and is _owned_ by Microsoft.  The features, capabilities, and potential performance that could be harnessed with this platform far exceed anything that the native database could ever be...

    Why on earth would Microsoft support many different database models when it can pursue one and focus R&D into it?  VAR's that customize a solution for every installation generally fail - why would you look at a DBMS platform any differently?

    As a community - we have need to start focusing on technologies that we can use to better help our customers integrate with other systems.  If you feel that native is better...great - use it as you see fit and support he prior versions of NAV.  When a database reaches 80 GB or a user count goes above 20 users - support the full table locking and limited 2 GB memory support as the binary is not compiled with the LARGE_IMAGE_ADDRESS_AWARE byte set (or set it yourself and see what happens).

    I, on the other hand, will move forward and support a stable and proven solution that we scale to hundreds of users - but still implement the 5 to 20 users without any issue.

    The native database is dead and should have been dead 5 years ago.  It's time to move on and use a DBMS platform that is the only one that we support so we can move past the C/SIDE limitations and really harness SQL Server and all of the technologies (i.e snapshot isolation mode, row count increases, data types, CLR integration, possible pre-compiled sprocs, reporting services natively) that it supports.

    Thank you again Stuart for being honest and giving us the heritage that we all need to follow to continue to drive this application in the market.  Our job should be simple now - give feedback to Microsoft so that we can create returns based applications for businesses that harness current technologies and how we can improve the DBMS to better handle business applications.

    I think the conversations that we'd have regarding the "right" DBMS to use would equate to a customer I worked with in the sales cycle (almost 7 years ago now) in which he asked what database model we supported and we stated the "proprietary C/SIDE database".  His response was pretty amusing..."What the **** is that?".  We then stated it supported SQL Server and he was happy (he wanted external integrations with DTS for some of their websites and t-log backups and log shipping for fault tolerance).  And yes - it was a 20 user implementation.  All of which was solved and implemented with the SQL platform and we never heard of any issues.

  • Stuart

    You make some good points of in support of SQL server that no one doubts in any case. A statement like "The native database is dead and should have been dead 5 years ago." is unfortunately rather glib if not emotional. Ask 10 journalists to generate statements and they can come up with a 100.

    The point is that for 5 to 20 users and even  some 30 user installation SQL server does not fit well.

    I have been involved in many a sale and installation where a bigger server (and definitely a second as server as recommended for 3 tier) would have been a clear no-go buying decision. Also the need for an in-house DB admin or full time IT support.

    The decision for Microsoft will finally be a financial decision. Things that count are potential lost of opportunity. Potential lost of acquired market segment. Existing implemented customers deciding to investigate alternatives. Microsoft shareholders desire for return on investment.

    If  smaller customer NAV sales makes up only 1% of revenue, it is an easy and done decision.  The real question at hand is what is the realistic contribution of the smaller implementations to NAV revenue? If I recall correctly decision of the Business Ready price structure was to provide a best benefit for smaller than 30 user implementations. Which surely must speak for itself.

    Microsoft previously more than once announced terminating support on certain versions of NAV, which was extended afterwards, based on customer demand.

    I simply believe the market’s reaction of both existing clients and prospective clients are not understood yet, neither the impact on Microsoft’s bottom line for the NAV product. Let’s see what happen first.

    Speaking on my own behalf, chances are good that we shall for some while continue to sell implement the last available version supporting the classic DB, if the new versions does not provide that support.

  • Thanks for all the comments - they're great reading.  Trust me, we really appreciate hearing your thoughts.

    Stuart

  • So a piece of very successful history is being left behind. Naturally, it causes a great discussion and emotional upheaval.

    I'm sure going with SQL Server makes the most business sense for Microsoft - it would be hard to argue that point. It was a path that Navision entered out of its own free will in early 1994 when it was decided to leave another piece of history behind: the IBM-based layers of system- and middleware.

    That choice, although not totally obvious at the time, turned out to be a great one. What was Navision Financials in 1995 is MS Dynamics in 2010. And although software and customers' preferences for it change slowly, you have to adapt.

    That said, let me bring out a cheer for one of the greatest pieces of software ever written, and for the few people who wrote it: the original Navision database, later renamed the C/SIDE DataBase. It's hard to describe in words how far ahead of its time it was in 1990. Changing field labels on the fly, FlowFields and FlowFilters, natively client/server, optimistic concurrency, Sum-Indexed Flow Technology - and we could go on and on.

    As a matter of fact, my little company still runs its G/L on that DB: in a DOS/character-based, beta-version 3.51 from 1993. It still chugs along, handling Y2K, and the changes of time without a glitch.

    It was, and is, the not-so-little DB that could :-)

    Erik

Page 1 of 1 (14 items)