Stephen Smith's Blog

Musings on Machine Learning…

Sage 300 ERP 2016 SQL Server Only

with 23 comments


If you were able to attend the Sage 300 ERP roadmap sessions at Sage Summit you would have heard that the next major release of Sage 300 ERP (named 2016 but released in 2015) will be dropping support for Pervasive.SQL and Oracle as database servers. This means the only supported database will be Microsoft SQL Server. Although we will support several versions of SQL Server long with the Azure SQL flavor.

The intent of this article is to help make sure everyone has plenty of advanced warning about this change. To help explain the rationale behind this decision, and to help people formulate migration plan if you aren’t already running SQL Server.



The first Windows version of Sage 300 ERP (then called CA-Accpac/2000) was released supporting one database which was good old Btrieve 6.15. We all have fond memories of those days when the world was much simpler, we just needed a simple robust database manager without any other real concerns. At that time we had a good bundling deal with Btrieve so we could include a database engine with every System Manager. At that time Btrieve was owned by Novell. At that point in time Btrieve was a good low cost database manager that supported transactioning, it was used by many ERPs, and was relatively easy to install and administer. Novell sold off Btrieve back to its original developers and that evolved into Pervasive.SQL and last year that was acquired by Actian.

Pervasive.SQL still has the same qualities that Btrieve 6.15 had, but it hasn’t really kept up with its competitors. SQL Server now has a free edition and Microsoft is much more favorable to doing bundling deals. Plus there are now many better low cost database alternatives such as SQLLite and MySQL.

Over that past years the higher end databases have become much easier to install and manage. Long gone are all the configurable parameters that would plague SQL Server installations (i.e. the defaults now work for most cases). So now Pervasive.SQL isn’t as easy to use.

Anyway Btrieve was the first database that Sage 300 ERP supported, and I think a lot of people have fond memories of Btrieve, but today it doesn’t seem to have a place anymore.

A lot of Sage 300 ERP installations require integrations to many other products, and nearly none of these support Pervasive.SQL. Hence if you want integration with BI tools, or other ERP related software, you are almost always forced to use SQL Server anyway. In the early days of Sage 300, SQL Server was very expensive and most products supported Btrieve as a low cost alternative, but today the need for that has disappeared and we are one of the last vendors to still be supporting Pervasive.SQL.



We’ve had Oracle support for a while now. However the sales numbers have never really justified the resources required to support this platform. Oracle tends to be the database of choice for larger companies that tend to be bigger than Sage 300’s target market. We’ve made a few government and large company sales because we support Oracle, but generally these customers would have been as well served by SQL Server.

Our perspective is that the demand for Oracle has waned and that they are really pursuing larger and larger companies and moving further and further away from our market segment.

Multiple Product Integrations

Most Sage 300 ERP sites these days involve multiple products working together such as Sage CRM and Sage HRMS. Generally people only want to work with one database system and the common one across the various products is SQL Server. Most products support a choice of databases, like Sage CRM supports Oracle and SQL Server and Sage HRMS supports FoxPro and SQL Server. To get a more uniform experience across all these products really only works well if you choose SQL Server. It’s generally nicer to have just one set up database operations for things like backup.

Further when you start to use more advanced cross product reporting tools, these can only do their job if all the products are based on the same database engine (so that SQL joins can work properly, etc.).

Database Architecture

The Sage 300 ERP architecture is still the same and supports multiple databases, whether we support another database than SQL Server in the future will depend on the future of the database market. It might be a lighter weight SQL engine like SQLLite is best. Or one of the new NoSQL databases that are becoming popular like HBase or MongoDB. Certainly the NoSQL databases support capabilities that SQL Server can only dream of. Similarly products like SQLLite also run on all the mobile an alternate operating systems opening up all sorts of other possibilities. Chances are these will be introduced in a hybrid manner combined with SQL Server rather than as solutions that handle 100% of our system’s needs.


For the short term we will be concentrating on SQL Server which means can use some features that are more specific to SQL Server. However one of our keys to success has been sticking to the core SQL engine functionality. That we work fine with SQL Express and Azure SQL (unlike a number of competitors). So we will be careful to ensure anything we do doesn’t break our database independence or our flexibility in supporting all flavors of SQL Server.

Moving to SQL

If you are running an unsupported database and want to move to Sage 300 ERP 2016 then you will need to convert the database. To convert from an unsupported database like Pervasive.SQL, DB2 or Oracle, you need to run Database Dump on your databases, create SQL databases for these in SQL Management Studio, create the entries in Database Setup and then run Database Load. Make sure that you update and test your backup/restore and disaster recovery plans to ensure that you are still protected.

The conversion must be done before upgrading, since the 2016 version doesn’t include the unsupported database drivers and can’t access these databases and hence can’t do a Database Dump on them.

If you leave Pervasive, DB2 or Oracle databases in Database Setup then these won’t show up in any sign on dialogs. We’ve changed the message when you run the desktop, so that if you don’t have any databases because they are unsupported, why this is the case and to let you run Database Setup.

If you don’t want to switch to SQL Server, it just means the last version you can upgrade to is Sage 300 ERP 2014. This will be supported for its normal lifecycle. When it goes out of support, of course your software will still operate. But you won’t be able to get any new Service Packs or Hotfixes. This should present a quite large window on when to switch. These days, nearly all new sales are SQL Server and the number of SQL installs is the largest share and of course every one already running SQL Server won’t be affected.


The database world is changing and Sage 300 ERP needs to change with it. That’s why we are making these changes. We hope that converting your Pervasive or Oracle databases to SQL Server won’t be too painful and that you will get quite a few long term benefits from this move.


Written by smist08

September 2, 2014 at 12:23 am

23 Responses

Subscribe to comments with RSS.

  1. […] Introduction If you were able to attend the Sage 300 ERP roadmap sessions at Sage Summit you would have heard that the next major release of Sage 300 ERP (named 2016 but released in 2015) will be d…  […]

    • Thanks for the explanation Stephen. Can you give us the current ballpark time-frame for the release of Sage 300 ERP 2016? We have moved most of our clients to MS-SQL but we need to plan for those still on Pervasive. Thank you.


      September 3, 2014 at 7:10 pm

      • Right now its on the road-map for Summit, which means July 2015. But take this as fairly approximate at this point.


        September 3, 2014 at 7:38 pm

  2. Safe to infer that Sage CRM and HRMS may drop databases other than MS SQL Server as well?

    Wayne Schulz

    September 2, 2014 at 4:26 pm

    • I can’t really speak to the other products. They have their own Product Managers and priorities. It would depend on what they are seeing from their customers and the direction they want to take their product.


      September 3, 2014 at 1:34 am

  3. This left me with mixed emotions. In days past Btrieve was great, but as you said time to move on. Would the intent be to push out the A4W database API in order to get the new SQL capabilities?

    Keith Schenkeveld

    September 2, 2014 at 11:46 pm

    • It opens up the possibility. Especially since now we only need to deal with the ODBC database driver and don’t have to worry about how to do things for Pervasive as well.


      September 3, 2014 at 1:34 am

  4. So we can finally have stored procedures? 😉


    September 3, 2014 at 10:24 pm

    • How about auto-increment values? Larger text (char) values?

      Keith Schenkeveld

      September 5, 2014 at 12:48 am

  5. Also, Variable Length Field (Varchar) as there is a LOT of wasted spaces… I think we talked about this in the past…

    Jaime Schmulson

    September 5, 2014 at 9:57 pm

  6. Longer records? MAX_RECORD_LENGTH is currently 4000. MSSQL rows are 8060, so it could be doubled which would be ideal as have sometimes needed to use two tables – but never needed to go to three.


    September 6, 2014 at 9:15 am

    • The only problem with this on is we already double MAX_RECORD_LENGTH for the Unicode build to allow those.


      September 6, 2014 at 4:47 pm

  7. “fond memories of Btrieve” – I don’t think so! Coming from the world of Accpac Plus with no database management experience or training, all of the consultants that I worked with back in the early Accpac for Windows days found Brrieve to be a nightmare. Depending on who you happened to get in tech support, you could get completely different, and opposing, answers as to proper configuration settings. And a setting that worked at one client site would break the next client’s installation. No, my memories of Btrieve are far from “fond”.

    Jim Love

    September 10, 2014 at 8:16 pm

  8. Steve,this was a long time coming and I don’t think anyone in the channel is surprised by it (it’s been hinted at before), but I’m left with mixed feelings because, if I’m understanding you correctly, you are NOT going to optimize Sage 300 ERP to take specific advantage of MS-SQL’s functionality, yet still limit it to that one database.

    In a way that’s the worst of both worlds….you’re saying that Sage 300 will still take the SQL performance/functionality hit (compared to better-performing MS-SQL optimized products like Dynamics) that is part and parcel of a “database independent” app, yet Sage 300 will still only support that one database (MS-SQL). Not sure how this is any advantage for the channel or the end-user.

    And WADR, maintaining Sage 300’s database independence on the slim chance that some nebulous “future DBMS” will come into existence that Sage feels it must support, seems very detrimenal. What are the chances that there will be any DBMS other than MS-SQL that would be a benefit to support within, say, the next 10 years? MySQL would’ve been the only other real option in years past, and its time seems to have come and gone.

    I think I speak for a large part of the channel when I request that, if you ARE going to now limit Sage 300 ERP to MS-SQL, we are all in favor of that if you PLEASE re-optimize the product to take advantage of the features and functionality of MS-SQKL. Not necesarily all at once, but certainly on an incemental basis, I hpe Sage 300 ERP is developed and enhanced to make use of MS-SQL’s specific functionality and put uis in a better competitive situation. Thank you.


    September 11, 2014 at 10:18 pm

  9. Since SQL Server will be the only supported database engine going forward, there will probably be a lot of interest in the Sage 300 ERP MS SQL Server runtime edition. The licensing of this edition however is quite vague as far as using third party report writer like F9 is concerned. i called Sage 300 ERP Technical Support yesterday and i was told that because F9 does not use API to access the Sage databases, it will be violating the SQL Server runtime licensing. Can i get confirmation if this is an accurate statement or is this just the personal opinion of the Technical Support Analyst that i talked to yesterday? I tried to look for the license agreement for the runtime edition but can’t find any.

    Rey C

    September 20, 2014 at 3:18 pm

  10. Pervasive was once in the cat birds seat offering both SQL and “NoSQL”. Now SQL Server + HBase seems to be the partnership direction Microsoft is taking to store transactional data in SQL and vast unstructured data from other activities such as web server marketing.

    boulton clive

    October 4, 2014 at 8:32 pm

    • Also notice Azure Search which is based on Elastic Search.


      October 6, 2014 at 4:21 pm

  11. Hi, I am running Sage AccPac 500 ERP 5.5A and would like to move to 6.0a/6.1 for the Web-Portal or online access.

    1) When I run the Database dump too, I have 15 database, I dump all of them, now how do I import them into MS SQL 2012 running on WIn Srv 2012 R2 ?

    1a) “create SQL databases for these in SQL Management Studio, create the entries in Database Setup and then run Database Load” Can you explain this a bit with an example of say 5 database ?

    2) What is the latest version of Sage AccPac ERP now?

    3) Can you do a write up of how to install Sage ERP for online using 3 VMs.
    vm1=win2012r2+sql-server 2012


    Ryan Dunbar (@DunbarRyan)

    February 27, 2015 at 6:55 pm

  12. Has Sage identified which version of Microsoft SQL Server will be supported? We are currently on 2005 and haven’t upgraded because it was continuing to be stable so we need to know if an upgrade on Microsoft SQL will be required.

    Eric Carlson

    March 26, 2015 at 3:55 pm

    • For both Sage 300 ERP 2014 and 2016 we support SQL Server 2012 and 2014. Plus if there is a newer version of SQL Server released then we will support that also.


      March 26, 2015 at 4:16 pm

  13. HELP, I just recently purchased Sage 300 and it is on the Pervasive Database. So I Can move it too SQL Server myself??

    Patrick L. Wimsatt

    March 27, 2018 at 8:24 pm

    • Sage 300 hasn’t supported Pervasive for an awful long time. Perhaps you should get your business partner to move the database over for you. Otherwise you would use DBDump/DBLoad to convert it.


      March 27, 2018 at 9:50 pm

Leave a Reply to smist08 Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: