Sage Line 50 and its network speed issues….

I find Sage to be a very frustrating company to deal with.  For 10 years or so this issue has never improved, so I am venting here…

My initial networking background was when I worked for a couple of Sage Solutions Centres.   I went through the pain of Sage Line 100 4GL crappieness on NT Networks.  (Which still exists today, though MMS is finally going to move to SQL Databases).

Anyway, about 85% of my clients run Sage Line 50.   It has to be said, that for the price, it really is a fantastic accounts package.   But it falls down in a huge way in one area.   Speed.

If you are a network administrator, and you have got to this post via google by typing “Sage Line 50 Slow”, let me tell you a secret….     No matter what the Sage Support person tells you on the phone, it does not matter how much you tweak your network, Sage Line 50 is always going to be slow.  

The main problem as I see it is that the .DTA data files are essentially still the same proprietary Microsoft DOS data files from the Sage Sterling for DOS days.   The ODBC Driver is a huge joke and runs slower than a fat bloke with one leg.

What is really frustrating is that Sages answer to every question is to blame the speed of the network.   They never admit that they have speed issues with the data access, yet it is obvious to anyone with a clue that this is the case.  

We have a load of clients that produce about 50 – 100 invoices per day, and are VERY happy with Line 50 apart from the speed of reports.    To get around this, we have got to the stage where we have to export all the Sage Tables, via the slow ODBC / SDO link to an Access database overnight.   We then run Crystal custom reports against this database.   To give you an idea, a report that takes 35 minutes if you link directly using the ODBC, takes about 10 seconds if you link to the access database.

Maybe I am oversimplifying, but maybe Sage should really consider portalling Line 50 to SQL / MSDE….

Oh, but wait…     then no one would buy MMS.

  54 Replies to “Sage Line 50 and its network speed issues….”

  1. August 1, 2006 at 4:56 am

    Very useful article on Sage Line 50. More true in it than in any other. We’ve been having lots of issues with ODBC driver for Sage Line 50, from being slow to not being able to find a friendly user manual anywhere on the web. Our product creates financial reports using different datasources (MS SQL, VFPRO, Progress, Sage …) and Sage is the only one that brings nightmares to our developers. I like the idea of converting DTA files to Access (in our case DBF files) and will go that way before Sage moves to more tech. advanced SQL.

  2. August 2, 2006 at 9:57 am

    Dragging the data overnight out to Access / DBF / SQL or whatever is the only way that you will get any speed.

    Thanks for your comment, I hope that others will post here with their own thoughts on the subject and Sage will take notice.

    I mean, come on… they release a new version of Line 50 about once every 6 – 9 months. Maybe they should stop with the features and work on the speed 🙂

  3. October 3, 2006 at 4:33 pm

    Might be worth looking at Sage Line 50 2007.

    Our initial testing whilst adding support for the new version to our packages suggests that certain operations such as looping through all the Sales Accounts are about 30% faster than Version 12.

  4. October 3, 2006 at 4:52 pm

    Hey Steve,

    THANKS for posting!

    That is very interesting, I will have a look at that as soon as possible!

  5. October 3, 2006 at 4:53 pm

    Also adding you to my blog list 🙂

  6. Garren
    October 3, 2006 at 6:18 pm

    Being the poor bloke that wrote the Sage-Access (SIS-you can explain the acronym Nick!) export for Nick I can tell you that after my initial testing on version 2007 the performance increase is nowhere near 30%. we loop through massive datasets and I would estimate that the increase is no greater than 10% I’m afraid. Essentially the ODBC driver hasnt drastically changed whatsoever.

  7. November 4, 2006 at 7:58 am

    I should have mentioned that we use the Sage Data Objects (the SDK) rather than ODBC so there may be some peformance difference between the two.

    Doen’t look like anyone is going to be using 2007 any time soon anyway!


  8. November 4, 2006 at 8:45 am

    Just revisted the figures to make sure.
    We have a Windows Service running continuously that loops through all the Sage Accounts using the sdk and writes details to database table every few minutes.

    On a 11mbit wireless lan using exactly the same code it takes

    For Line 50 v12

    13:33:05 LoadSageAccountsHarness – Time to load 3968 records = 139 seconds
    13:33:05 LoadSageAccountsHarness – Estimated Load Rate per thousand Sales records = 34.48 seconds

    For line 50 2007

    14:39:34 LoadSageAccountsHarness – Time to load 3968 records = 76 seconds
    14:39:34 LoadSageAccountsHarness – Estimated Load Rate per thousand Sales records = 19.23 seconds

    when I get some time I’ll redo the test on the Lan but I think we got a similiar performance increase.

  9. December 28, 2006 at 6:25 am

    I spoke to Sage after reading about them signing up with MySQL recently. They say that th enext release of Line 50 in Aug ’07 should be ported over to MySQL! We can only hope that this is true.

  10. June 8, 2007 at 6:00 am

    reading this has helped us we have spent 12 months trying to sort out speed issues running 1gb network and server 2003 it can take 15 seconds to open a customer record !!! and scrolling lists if more than 1 person on the network is really slow thought that buying the new version 12 might help with speed issues from our old one to no avail old version 8.20

  11. July 20, 2007 at 8:58 am

    We have been plagued by Sage speed issues for months now. The biggest concern is how much Sage Line 50 slows down our entire network. For example when we backup our sage data onto a memory stick at night before leaving the office our networks runs so slowly we can do nothing else for several minuites.

    There are numerous design flaws with line 50 making every day tasks a chore. The need to archive data frequently is a serious design flaw.

  12. September 13, 2007 at 5:53 am

    What I find interesting – and it lets Sage off the hook to some degree, is that speed is not an issue in Safe Mode. So Sage argue that its a Windows process which slows the whole network down – a process which isnt started in Safe Mode. So if someone could tell me which windows process it is I would love to know. Ive tried killing the anti virus etc etc.

    The support chap from Sage told me that “most Sage customers have gigabyte networks” and that they recommend you have a gigabyte network for running Sage!
    Yea right.


  13. September 13, 2007 at 6:36 am

    Well, hang on there Mick….

    There are some factors here. Running anything in safe mode will be quicker. Disabling AV Scanning of the Sage folders also makes it quicker….

    But… there is a CORE thing here.. Running sage *over the network* is slower, because of the locking technology they use… end of story.

    Running sage on a single PC has never really been a bother for me. Safe mode or not.

    Roll on the SQL version…

    Beware the support monkeys that read off the usual scripts…

  14. Graeme Barrett
    October 30, 2007 at 2:55 am

    I moved to Line 50 V2007 a couple of months ago and the big difference I noticed in speed is how much slower it is to print customer invoices – at least an extra 15 seconds compared to the previous version.

  15. Access Office Industries
    January 7, 2008 at 6:03 am

    oohhhh forgot to tell you all

    Have turned of antivirus scanning of DTA files
    Have used a network Share and not unc path
    Have disabled oportunistic locking on server

    And speed up suggestion well accepted

  16. Bill Shankley
    February 28, 2008 at 2:51 am

    We’ve had these issues but I found a decent client machine makes a difference, if you have a bunch of old Dells running 256mb of RAM and a celeron processor don’t expect any change in terms of speed. That’s not to say there aren’t obvious networking floors with the Line 50 Package but I found upgrading a couple of members of staffs machines did go a little way to ease the groans Sage Line 50 brings.

  17. D.McClouglin
    March 7, 2008 at 7:11 am

    Not sure how sage got away with releasing a software package that runs so poor, regardless of any extra features. I store the sage data files on a 2 X 3.2Ghz Zeon Processor Server, 8GB memory, 1GB Network and only five clients machines (All with 3.0GHz Processor and 2GB Memory, 1GB Network Speed) and its still extremely slow to run any of the reports. Its also takes several minutes to open up activity reports for some of our larger customer accounts. Couldnt possibly invest any more in hardware to counter act this issue.

    After so long running sage i think its simply time to make a drastic change to a different accounts package as Sage Accounts 2008 is simply unacceptable from an administrators point of view. Its also a dissapointment and extreme hassle to all loyal users that have used to and working on previous versions of sage. (Not that they care one bit!)

    I agree completly with above. SQL is the way forward for Sage. According to Sage technical support there is a new Sage Online to be released soon id imagine they would need to use SQL for that, unless their planning to host all clients accounts data? Overall it might finally be a step in the right direction.

  18. Edmund
    March 20, 2008 at 8:13 am

    I’m also facing problems with Sage on an SBS network.

    With the data and program on a workstation, Sage runs “OK”;
    With the data shared from another workstation, Sage runs slower but still “OK”;
    With the data on the SBS 2003 server, Sage runs like a complete dog.

    As far as we know, there are no other network performance related issues with the SBS server and general file access / transfer seems good.

    Anyone have any ideas how to ensure that performance with the data on SBS is not worse than when shared from a workstation?

  19. Kumar
    May 7, 2008 at 4:21 am

    Sage Line50 is a good product. Having used sage over 14 years, let me tell you their technical support is USELESS. Every time i have called them, their solution is “have you done your backup?”.

    Programmer/Network support engineer.

  20. Dan
    June 6, 2008 at 5:57 am

    Sage Line 50 (v12) is a network admins nightmare! We have A LOT of data (customer records) which the MD refuses to remove but demands rapid access to data. It has got so bad we plan to export customer records out of sage into a mysql database and build a web based front end for the sales staff to track down previous orders. Then remove customer data from sage that is older than 4 months.

    Working directly on the server performs well but I defy anyone who claims line50 is an ideal multi-user package.

    *** Ensure you exclude .DTA files from on-access & scheduled anti-virus scans. ***

  21. Joe
    July 8, 2008 at 6:22 am

    I put the client & data on the sbs server, then have clients TS into it the server and use that copy. This runs much quicker as it’s basiclally just a local install…

  22. Martin
    August 24, 2008 at 6:08 pm

    I am just about to have multiuser Line 50 moved from a peer to peer network onto an SBS2003 server! This doesn’t make good reading. Performance at the moment is satisfactory, but not blistering & we do suffer occasional multiuser issues.

    I cant say that I have found Sage Support to be as bad as is reported here, they have generally provided satisfactory resolution to any issues I have had.

  23. Craig mackay
    November 20, 2008 at 3:32 pm

    try running Sage 2009!!! its worse than any previous version – runs so slow as to be almost useless!!

  24. NickWhittome
    November 20, 2008 at 4:31 pm

    Hi Craig,

    Believe it or not, I have not looked at it. If they made it worse I am not sure how that could be possible.

    I was meant to be invited to the beta… I had understood they were going down the SQL route? Maybe that is the next version….

  25. November 30, 2008 at 11:30 am

    Just installed a “data” server for a small business (3 users) running v10 and discovered that a profit report on the previous local PC ran in 27 secs but moving the data to a high spec standalone (whilst not compromising basic invoicing creation) took 50 minutes to run the same report.
    Really useful comments here – thanks everybody.

    February 22, 2009 at 5:53 pm

    The last time I looked at Sage Line 50 was in 2001. It is not a well architected package and the best thing to do was to dump the data files into something sensible such as SQL and then work from there.

    I wrote a series of programs in c# which looped through and dumped the files. This was quite straightforward once one had unpicked the unneccesarily complex data structures which go back to DOS days when data storage was an issue.

    Anyway, I now need to have read and write access to Sage Line 50 version 14 and do not fancy going through that again. Where can I find the sage file structures on the internet or, better still, some publicly available set of routines to do this? Regrettably, appears to have been shut down.

  27. Andrew M
    February 24, 2009 at 9:04 am

    this is great its nice to know that i am not completely insane and that the thorn in my side is SAGE. i have Line 50 v14 working through SBS2003 linking to Windows XP SP3, and they are all incredibly slow, again sage support says its a network error with no help at all. the remainder of the network is running brilliantly and is a gigabit network. any advice would be appreciated

  28. Phil H
    March 12, 2009 at 8:02 am

    We have always had speed issues with Sage, and it seems to get worse in the newer versions.

    I ended up doing exactly what hugh.meares did with the scripts, only in Perl, but sage virtually hangs for other users while the database is being dumped and it has never worked all that reliably.

    Have just come accross jitterbit though which may take much of the pain out of exporting the data to a postgres server.

  29. Kal
    March 13, 2009 at 8:09 am

    What are the issues with running Sage line 50 2009 on a Novell Netware Server V6.5 (data storeage).There seems to be no mention anywhere of Sage compatibility with Netware. We are currently experiancing very slow performance. Have been told by Sage support we should be running across a 1GB network!

  30. david h
    March 18, 2009 at 6:21 am

    The slowness of Sage gets worse-our new v.15 is u/s
    We did not have a problem with v.8.
    All Sage say is that the computer needs upgrading.
    Everyone should make a formal complaint to Sage-the have a hit list of improvements required

  31. steogede
    March 23, 2009 at 11:24 am

    Anybody know what has happened to Sage’s MySQL migration plans for Line 50. I can’t see any news about this since 2007. It’s about time Sage moved into the 20 century (21st would be expecting a little too much).

  32. Michael
    June 4, 2009 at 1:17 am

    We had same problem with Line 50 2009.

    Sage lives on samba server ver 3.032
    workstations – Win XP SP3
    network – 1Gb

    After our changes: (smb.conf)

    lock spin time = 15
    lock spin count = 200
    oplocks = True
    level2 oplocks = True
    veto oplock files = /*.DTA

    and excluded *.DTA files from antivirus scanner (on workstations).

    We got hudge speed increase (nearly 10 times faster).

  33. Tom H
    June 17, 2009 at 6:34 pm

    It is so true what you say about Sage tech. support blaming it on the speed of your network and then stating the server “must” run on Windows Server. I have had locking problems on sage over multiple versions of Sage Accounts.

    Then with the 2009 version, Bank reconciliation freezes all clients on the network. I have heard the pdf driver Sage utilises may be to blame, but Sage have provided no solution to my problem and explaining a software issue to a client becomes frustrating for me and of course the client.

    If anyone out there has tips for the Bank rec problem please let me know.

  34. Harry
    October 7, 2009 at 8:06 am

    Have just more Sage data files to a network server – a week bank rec now takes about 15 mins to process and locks everyone else out of the system while it does it! Window says “Not responding” and blanks out. Looks like we might have to move it back to a local machine – pathetic!

  35. October 7, 2009 at 10:16 am

    Sage have an new database back end in Beta testing, it uses the very well known and highly reliable MySQL database.

    It is anticipated “shortly” as a mid season release alongside the current release of V2010 (V16)

    MySQL runs great under Linux, but I have no idea if Sage will be supporting it. Providing it works, I guess independents like me will support it ourselves.

    Linux/SMB as a host for Sage50 data does not seem to have the same amount of freezing as Windows servers

  36. NickWhittome
    October 7, 2009 at 11:29 am

    Hi Bruce 🙂

    I have been hearing that for 5 years now… is this real? Sources?

  37. Alan
    October 21, 2009 at 11:08 am

    hi Guys
    I have been reading your comments with great interest.
    We are running the new sage 50 pro 2010 v16. on 6 pc’s with
    windows 2000 v5 sp4 on the server (dell poweredge 600 sc. 4cpu 2.4GHz 512Mb ram.2003. While pontificating on the window sill -sage in hand looking at the staff looking at each other waiting for sage i decided to increase the ram in an older (dell optiplex GX60)to 2GB. The difference was not enough to restrain from potential suicide.
    I am not a techi so would it help if I increased server ram, although I dont see how. Should I replace the pc’s with super fast new ones which I can’t really afford.
    Thanks for any views.

  38. October 22, 2009 at 4:17 am

    The MySQL press release dates from 2006 !!

  39. Bill
    December 9, 2009 at 6:41 am

    Quote “Anyway, I now need to have read and write access to Sage Line 50 version 14 and do not fancy going through that again. Where can I find the sage file structures on the internet or, better still, some publicly available set of routines to do this? Regrettably, appears to have been shut down.”

    This would be massively useful for me, is there anyway to do this?

  40. jack benson
    December 22, 2009 at 2:29 pm


    this is an excerpt from a reply to an email today where i asked Sage Support again for an SQL version of sage Line 50 OR for native SQL drivers for Sage Line 50:

    “Firstly, Sage 50 is currently in the process of implementing an SQL server database, and we are currently testing this version on clients sites as we speak, if all goes well we hope to go live with SQL within the next year, with possibly V17 being the first version, however its not a gaurentee yet as were still testing”

    They have said the Customer Development Team will get in touch soon with me.. i’ll keep you posted… but dont expect and SQL Sage 50 for Xmas this year 🙂

  41. December 23, 2009 at 10:04 am

    Hi everyone,

    Been reading the comments with interest, we have just upgraded to Sage accounts 2010 with NO END of speed issues. It now freezes for 10 secs when accessing our suppliers records, logging in now takes 30 secs, 10 secs to print an invoice.
    All of these were instantaneous and now take an unacceptable time to process. And sage tech support’s answer? “It’s a network issue”. Why am I not surprised?

  42. Peter Jackson
    January 15, 2010 at 12:10 pm


    How interesting. I’ve just searched hunting for Sage speed issues and found this site. We get problems with just 3 users ,sometimes only 2 users . Bank rec freezing . We are currently peer to peer on high spec machines. Has anyone tried Windows Home Server?

  43. January 22, 2010 at 9:55 am

    These problems re. performance basically came after win98. It must have something to do with security and remote data access. If you put the server files on a win98 pc everything should be fine as win98 securityauthentication checking is limited.

    I suppose you could say it is an MS issue or how do we get a PC/Server with the sage data files not to check/authenticate remote sharing/permissions (NOS XP/vista/SBS203+ etc).

    I’m still trying various options…. the only area that i know that is very very slow is invoicing on a remote client..

    Useful info here but SQL DB required or workaround maybe is to run shared Sage DATA on win98 client!!!

    v14 is still really bad.

  44. January 24, 2010 at 10:18 am

    We use line50 and run off SMB on a linux box.
    We have all the suggested options from various forums done, turn off av checking on .dta and the paths etc and still had a slight speed issue.
    On looking at the logs on the linux box I saw the issue.
    When a users PC connects to the SMB share via explorer , the username and group are that of the user , so for me, user = steve , group = steve , and these are configured in the smb.conf correctly. But for some reason, when running sage accounts from the same pc, when it ( the software ) connects to the datafile on the SMB, it uses the account , user = pcguest and group = pcguest.
    Once I saw that , I modified the smb.conf to suit, and the network speed it very fast now.
    We run a gigabit network, and when I monitor the network speed when doing something in sage, I am getting 60 MB ( megabytes ) per second and it is “almost” as fast as having the .dta as on your HDD.
    Depending on what flavour of windows you are using, you may always wish to stop the virus scanning from
    the locations below, inclusing all subfolders

    /program files/sage
    /program files/common files/sage line 50
    /program files/common files/sage SBD
    /program files/common files/sage shared
    /program files/common files/sage report designer xxxx ( where xxxx is the year )
    and in vista,
    allow hidden files in explorer , then

  45. Graham Elliott
    February 9, 2010 at 2:51 am

    Re Alans comment above I’ve just loaded version 16 and am having the same issues precisely. We have upgraded our network speed on advisement from Sage to 1Gb fromm 100mb, differecne is zero. All of our equipment is well over the minimum requirement but under the “recommended” arse covering level on the packaging. I have been running Line50 for many years now, and the only thing I can add to this thread is once you manage to get it running do not upgarde ever!!! I have had the same nonsense every time I’ve updated, and only loaded this version due to the help desk a) Telling me that they are no longer going to support v12 and b) that 16 was essentially the same as 15 (cosmetic changes only) which had run with no problems for the last 12 months. All of which it trasnpires is absolute crap.

    My time is now being consumed by a search for alternative software. All suggestions are welcome incidentally. The faster I can get my business away from Sage the better IMHO.

  46. Duncan
    March 25, 2010 at 12:32 pm

    File access from the client application over the network is a real killer. Line50 is very I/O intensive. Whatever network infrastructure you run, doing file I/O over the network will be a problem because of latency not throughput. The only successful solution I know is to put the application (and data files) on a terminal server and have users access it via Remote Desktop. It is then running on the local host and doesn’t have an I/O problem. It is not a supported config but it works very well.

    Then you can move on to SSDs for a further boost…

  47. Ben
    May 26, 2010 at 7:33 am

    We use Terminal Services exactly because of this locking/network speed problem.

    Install SQL Server Express on the server where the DTA files reside, set up a System DSN and a Linked Server. Then create views like this:

    create view INVOICE_ITEM
    as select * from openquery(SAGELINE50PRACTICE, “select * from INVOICE_ITEM”)

    You can then use SQL server as a bridge to get your data remotely. For some reason only returns the first line of INVOICES though???

  48. One legged Fatbloke
    June 21, 2010 at 8:49 am

    Thanks Nick

    Your rant has served me well in not wasting anymore time trying to find a fix.

    I only have 3 machines but a combination of slow speed and a new little niggle of Windows 7 hiding any search criteria BEHIND the report window and sitting there waiting for a response is driving us all nuts.

    Since so many people find this rant via google could you set up a poll for us to present to Sage at sometime in the future. Something like…

    option 1
    Dear Sage please fix speed issues

    option 2
    Dear Sage please do nothing and watch us all go elsewhere


    (PS lost the race!)

  49. July 20, 2010 at 4:31 am

    Re. The bank reconciliation report speed issue (V16):

    If you do not want to actually print the report; when asked to enter a “statement reference” try leaving the field blank.
    This will prevent sage from trying to produce a .pdf in the background (which is what causes the huge slowdown)
    In one of my customer’s experience; this improved the reconciliation time from over 5 minutes to less than 10 seconds.

    Hope this helps…

  50. Tom
    August 3, 2010 at 3:56 pm

    We have line 50 v14 running, and improved the network performance massively by actually slowing down the network to 100mbps half duplex. Also eliminated the crashing and data corruption we used to get every few months.

    Still have issues with stock records disappearing, stock transactions drilling down to entirely unrelated purchase orders, and lines vanishing from invoices sometimes, while leaving the totals intact! But what really annoys me now if the fact that the sage ODBC does not work with our sage data anymore.

    We will of course be upgrading shortly to a mysql based solution.

  51. Colin
    November 22, 2010 at 7:10 am

    Had an email from a client which may well help out some of you.

    Had to take the plunge and get Sage out to us to try to sort or speed issues after 8 hours the fix was!!!!!!!!!!! (very expensive)
    Install the 2008 template for delivery notes ??????????
    It seems the 2011 version looks for multiple delivery addresses and if you have not got one looks in every account for one hence the delay but if you use a server it appears quicker they have known about it for 2 years and have not a fix yet!!
    Bloody quick now tho

    This may well be an issue for 2009 and 2010 also worth a try.


  52. Colin Gowler
    November 22, 2010 at 7:19 am

    This may well help out a few of you fellow suffers out there. It may well be the problem for 2009 and 2010 as it’s been known for 2 years.

    Had to take the plunge and get Sage out to us to try to sort or speed issues after 8 hours the fix was!!!!!!!!!!!
    Install the 2008 template for delivery notes ??????????
    It seems the 2011 version looks for multiple delivery addresses and if you have not got one looks in every account for one hence the delay but if you use a server it appears quicker they have known about it for 2 years and have not a fix yet!!
    Bloody quick now tho

  53. notsoold
    November 22, 2010 at 8:05 am

    This may help some of you perhaps for 2209 and 2010 aswell.

    Had to take the plunge and get Sage out to us to try to sort or speed issues after 8 hours the fix was!!!!!!!!!!!
    Install the 2008 template for delivery notes ??????????
    It seems the 2011 version looks for multiple delivery addresses and if you have not got one looks in every account for one hence the delay but if you use a server it appears quicker they have known about it for 2 years and have not a fix yet!!
    Bloody quick now tho

  54. Arty
    November 25, 2010 at 9:20 am

    We have line 50 v16 running, and have massive crashing, freezing & data corruption every day or other day. We have had out I.T man increase memory & stop the antivirus access to DTA files..

    However, we have still not eliminated the crashing and data corruption issue

    There are also some issues with Sales Order Processing records disappearing, going out of line, receipt allocation freezing…and many other issues.
    Should be upgrade to a mysql based solution?

    HELP…advice strongly needed

Leave a Reply

Your email address will not be published. Required fields are marked *

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