Updated 22 Dec 2018
Note: - Although comments below refer to AR2017, the same applies to AR2019. Since AR2020 the number of these errors dropped significantly by allowing use of up to 4GB of RAM, provided this is available on your system.

However these errors have not been entirely eliminated and so the comments below should be read in this context.



The concept of AR2017 is terrific, a modern database design, online access for multiple users from multiple locations. Sadly for many the reality is anything but terrific.

Where MYOB's AR2017 fails is in the design and coding (or implementation). As a result, in numerous places on the MYOB Community Forum MYOB moderators recommend the company file size be kept below 200MB for optimal performance. Clearly this should not be the case.

However as company files get bigger, AR2017 users are encountering more and more crashes. We too recently started encountering regular System.OutOfMemoryException related crashes with larger files, and decided to investigate.





In our view, one particular area where MYOB stuffed up relates to memory management, specifically the Managed Heap.

AR2017 is a .NET Framework Application. .NET Framework Applications have inbuilt Garbage-Collection. Basically, if coded correctly, the framework manages memory. Importantly it frees up memory when no longer required by the application.

This is what Microsoft writes:
"The .NET Framework is a garbage-collected runtime, so that in most apps, memory use is not a problem. But in long-running applications like web services and applications, and in devices that have a limited amount of memory, the accumulation of objects in memory can impact the performance of the app and the device that it runs on. Excessive memory use can starve the application and the machine of resources if the garbage collector is running too often, or if the operating system is forced to move memory between RAM and disk. In the worst case, an app can crash with an 'Out of memory' exception" - emphasis added.

Irrespective of installed RAM, a windows 32bit application can get a maximum of 2GB memory allocated to it by the System. Study the memory map while AR2017 is running any 'building' process and you will see the Managed Heap grow and grow. By a 'building process' we mean generating a report, upgrading a file from v19, etc.

Normally the amount of memory used grows, and shrinks as the application finishes with the data it is processing. This does not happen when AR2017 is generating a report. The memory being used continues to grow, (specifically the Managed Heap - the area of memory controlled by the .NET garbage collector) even though the data has been dumped into the report. And if the next memory request exceeds the critical limit Windows can allocate, AR2017 will crash - you will see an Error message - System.OutofMemoryException.



While it may seem reasonable to hold all the data for a report in memory, the amount of memory AR2017 is using is way beyond the size of the data it is dealing with.

To illustrate that this is a coding stuff up, and not a file size issue or RAM issue, get hold of your AR2017.2 Clearwater sample file and import 2300 new Items - or see downloads at bottom of this page if you want to save some time - importing in AR2017 takes forever! The Clearwater file size will grow from its original 10MB to 14MB - it is important to note that all of the data in this file totals less than 14MB. Next open Task Manager and under View > Select Columns - tick 'Memory - Working Set'.

We realise Task Manager is not the best tool to use as it has its limitations - there are better tools, however every Windows computer already has Task Manager installed and it will demonstrate what is happening. Working Set (Memory) is a subset of the total memory committed an application - the maximum being 2GB. Within the Working Set is the Managed Heap (as well as other components). Task Manager does not provide a breakdown, however for our purposes Task Manager will show the Working Set grow (and shrink). As mentioned above, AR2017 crashes if it requires more memory than the maximum the System can allocate to it, ie 2GB.

Select the Processes tab and highlight Huxley.Application.exe. Make a note of the size of the Working Set. Approx 352MB with this Clearwater file - as you can see in the image below.



Now in AR2017, select Reports > Index to Reports. A new Reports window will open, select Inventory > Items Sales History. Select Display Report - a new window will soon open with the Items Sales History report, and AR2017 will start building this report page by page. Watch the Working Set size grow in Task Manager. The report should grow to 45 pages.

Apart from the 35 items that were already in this file, there are no transactions for the bulk of the Items. And the total data in this company file is less than 14MB. As the report is being built, notice how the size of the memory Working Set grows to around 1GB (from about 352MB), that's almost 650MB of memory used to build a report that will have 1-2MB of data, mostly zeroes. AR2017 is accummulating objects in memory and not releasing them.

Depending on your computer, some users will find AR2017 will crash before it completes the report. Others will find the report completes. You will notice that when you close the Report window, the memory Working Set stays at the high level, is still not released. In fact if you click Display Report again, AR2017 will try to build the report again, without releasing the original memory in the Working Set. The size of the Working Set will continue to grow until AR2017 crashes.

For the record, we removed any unrequired processes from memory before testing. When AR2017 crashed, the memory Working Set was 1042MB and Free memory was over 600MB - in other words even within the 4GB for a 32 Bit application, there was over 600MB Free to be used. (Available Memory was over 4.5GB) The limit was clearly the maximum 2GB available to the application, not a lack of RAM as the MYOB Community Forum suggests.

Notice also how long it takes to generate this report (MYOB developer - please explain!) - remember we are using a tiny Clearwater file, and that we just added these items, there are no transactions for the 2300 Items to analyse. The Clearwater file itself has less than 400 transactions in it! - so why take so long? Even with a tiny file, AR2017 cannot generate a Items Sales History report for more than around 2400 Items without crashing on a Windows 7 system. If AR2017 did not crash on your system, try adding a further 200 Items.

As users' files get larger, they experience more and more System.OutOfMemoryException errors. Some users can't upgrade their files. When upgrading, 'Processing Sale and Purchase Transactions' also causes the memory Working Set to grow and grow - odd given once the transaction has been written to the new database, there is no reason why it still needs to remain in memory. Other users can't generate Journal reports, or any History reports.



With the database (SQLCE) chosen by MYOB for AR2017, the only 'limit' is a file size limit of 4GB. In theory there is no limit to the number of Items, or Customers, or Jobs etc. However due to how MYOB has coded their software, on a Windows 7 machine, AR2017 can't have more than around 2500 Items otherwise it cannot generate an Item Sales History Report. And why it takes so long to build this report, for a file with less than 400 transactions is bizarre!!!!

The same can be said of Jobs, Customers etc. Generate a Sales History Report for Customers or a Job History Report and watch the memory Working Set size grow. If you have too many, AR2017 will crash as it hits the 2GB overall limit before all the Customers or Jobs can be processed (using the strange method adopted by MYOB). Once Customers/Jobs etc exceeds a certain number, AR2017 will not be able to generate History Reports. Even with only a small number of Items, Customers and Jobs, as the number of transactions increase, AR2017 will not be able to generate Journal Reports, such as the Sales & Receivables Journal Report.



FYI - MYOB launched AR2017 in 2011 - then known as AR2011. In Feb 2013 Microsoft announced they had 'deprecated' both the software underpinning the Report Writing functions as well as the Database itself (SQLCE). This means no more updates, no more development, however Microsoft will 'support' the product until July 2021*. Will MYOB keep using an 'unsupported' product, or will they have to develop AR Mk II by 2021?

MYOB have known about this since early 2013 and are rather silent on the issue - perhaps they don't want to make their investors (or customers) nervous.

If developing AR Mk II hopefully they will have learned from AR Mk I, and won't make the same mistakes with AR Mk II.

Note:
The minimum specs for AR2017 is Windows 7 SP1 with 2GB of RAM. Our comments above refer to a Windows 7 SP1 64 bit machine with 8GB RAM installed, and file on desktop - NOT cloud. As AR2017 is a 32 bit program, more RAM will make no difference, the maximum AR2017 can access is 2GB, and less for the Working Set as part of the total memory is required for other purposes.

From our testing, on the Windows 7 machine the max cut off point for generating an Items Sales History Report was around 2500 Items. On a Windows 10 Machine this was higher, approx 3500 Items due to differences in how Windows 10 manages memory. As your AR2017 file gets bigger, you will get less memory related crashes on Windows 10 (as opposed to Windows 7), however the same principle applies. Once AR2017 requires more memory (due to how it was coded) than the System can provide within the 2GB overall limit, AR2017 will crash. Even with a tiny file!

Our testing was limited to report building and file upgrading. It is not clear whether memory management is a factor in the overall sub-standard performance of AR2017, for example when processing Sales. We did note that when importing Items, AR2017 handles memory correctly, in that the memory is released progressively and does not continue to grow as it does with report writing.

There are clearly other factors that are to blame for the unbearably slow import process. MYOB Moderators attribute this is the fact that when importing you are 'directly' interacting with the database and there are a large number of checks to be made - see here. Not sure how this differs to manually entering a Sales Invoice or adding an Item - both involve directly interacting with the database and various checks that have to be made. Just how many check are involved with importing timesheets anyway?

Won't releasing AR2017 as a 64 bit application solve this memory issue? - yes, as Windows can allocate 4GB to the application instead of 2GB. However, from our point of view, for the sake of users, we would prefer MYOB fixed the processes. Taking so long to generate a simple report in a tiny Clearwater file with less than 400 transactions - this won't change if you make it a 64 bit application. The performance MUST be improved, not just the capacity.

* source - https://en.wikipedia.org/wiki/SQL_Server_Compact

Downloads:

Import File for 2300 Items
Import File for 200 Additional Items 1
Import File for 200 Additional Items 2
Original AR2017.2 Plus Clearwater File
AR2017.2 Plus Clearwater File with 2300 Items imported
AR2017.2 Plus Clearwater File with 2700 Items imported
AR2017.2 Plus Clearwater File with 5225 Items imported - will crash on any system