How big is my Sage Line 50 database??

[billshankley]

Hi,

Couple of questions,

What is an accurate way of determining how big a Sage Line 50 database is?

And what are the maximum database size limits advised for a typical stable installation of Line 50?

Thanks,

[leyburnsolutions]

The database is made up of over 200 seperate .DTA files all in the ACCDATA folder so the size of the files in that folder will give you an idea of the total size.

Technically, any of the files can have 4 billion records in - recent conversations with Sage suggest that they have 'made up' figures for limits of 20,000 customer records and 100,000 transactions on the Audit Trail. These figures are completely arbitrary and are used, in my opinion, as a way to sell upgrade to Sage 200. If you go to Help -> About there are figures there as to how many customer, supplier, transaction etc records are currently in the data.

I worked for Sage for 9 years with Sage 50 and at no time when I was there were these figures mentioned - I've seen Sage datasets with over 1,000,000 transactions on the Audit Trail that were running with no problems.

John

[brucedenney]

As big a bit of string is long.

Depends on what you define as database!

And what you mean by size!

There are finite limits to the number of records, there are finite sizes for the fields in the records, in addition to the main databases in accdata there are items such as customer memos, bank statements reconciliation histories that are stored in text/pdf files as part of the installation, the VAT returns information is stored in XML files. What about the archives do you consider these to be part of the database?

And so on... and so on.

[billshankley]

John, great post thanks.

Bruce thanks, in some ways I wanted the question to be a bit vague for the following reason.

Sage 200 is often put forward as the solution for when you "get too big for Line 50" or for when Line 50 starts to wobble (software hanging, slow load times, lockouts, crashes, data corruption blah blah blah), (can I also voice my irritation at the sales reps who try to make this sound like some sort of natural progression for the Line 50 software!) I guess my questions are

1) What exactly is too big?

2) Is there any tangible way of measuring whether you are reaching/exceeding the limitations of this archaic database or do you simply have to wait for the wheels to fall off?

3) What are these finite record limits you mentioned?

Thanks

[leyburnsolutions]

1) What exactly is too big?

More often than not, 'too big' is defined by the way that the system is setup (anti virus, network settings etc) rather than the number of records. As I mentioned, data is stored across multiple files so, for example, the customer data file might have 100,000 records, the supplier file 50,000 and the transactions files in excess of 1,000,000.

2) Is there any tangible way of measuring whether you are reaching/exceeding the limitations of this archaic database or do you simply have to wait for the wheels to fall off?

There is no specific 'shut off' point where Sage 50 becomes unusable, again a lot has to do with the setup - a well configured system with high spec machines would handle a large set of data much better than a setup with minimum specification machines.

As the database gets larger generally the first thing that users notice is the speed reducing (albeit this was vastly improved in v2012 and again in v2013) particularly when it comes to reporting. A large dataset doesn't make a huge difference to day to day data input but does make a difference to the production of reports.

3) What are these finite record limits you mentioned?

Due to the internal code, the finite limit of records for any one DTA file is, as I mentioned 4 billion (4294967295 to be exact). Certain files, do have a limit but that is just down to the way that Sage works - SETUP.DTA for example which holds the company details only ever has a single record in it. DEPARTMENT.DTA is fixed at 1,000 records as that is how many departments you can have.

John

[billshankley]

John again, thanks. You have pretty much summed up in a few sentences what I have gathered from all over the web. Lots of groans but often problems were network or AV issues. We currently have no such issues but forewarned is forearmed.

The only area where I see a real "size" issue is with the number of users, the Sage 50 flat file system is going to cause increasing numbers of lockouts/errors as your concurrent users increase, Sage appear to have capped latter versions of Sage Line 50 to 10 users, support say you can go higher but the max they advise is between 10-13 and beyond 7 or 8 users to expect performance degradation. Would you agree with this?

[leyburnsolutions]

Would you agree with this?

I would agree with that - one of the biggest issues, because of the file system Sage use, is locking and the more users, the worse it gets.

John

[brucedenney]

I have seen systems which are very large and that work fine.

There is an element of up-sell going on, but the reality is that Sage 50 has a poor database back end and unless you invest in a good terminal server, it becomes a real pain with larger numbers of users and heavy use.

I would say the end user experiance is really the gauge. If the end user is having a bad time, then upgrading is the solution.

Of course upgrading does not have to mean software, if you are running on anything less than the recommended specification then hardware upgrades will help, better configuration (anti-virus, reporting cache and server side reporting) can also help and finally moving to terminal services has greatly extended the life of Sage 50 for many large users.

There is a commercial gain if they get you to buy Sage 200 and it does resolve issues so there is not much incentive to help you keep Sage 50 going.

The reality is that if you are prepared to work at it, Sage 50 can be used for very large installations with satisfactory performance.

Find a company that do not offer Sage 200 and ask them to help you stay on Sage 50 and you might find there is more life left than you think.