Posts Tagged ‘mysql’

WordPress ends up with wrong upload directory after moving servers

Monday, August 15th, 2011

If you’ve moved WordPress from one server (or home directory) to another, everything looks fine until you come to upload a file. It then complains that it can’t write to the upload directory. Something like:


Unable to create directory /usr/home/username/wp-content/uploads/xxx/yy. Is its parent directory writable by the server?

A search through the PHP config files doesn’t reveal a path to the upload directory, and if it’s possible to change it from the Dashboard I’ve yet to find where.

The only remaining option was the mySQL database, and fishing around in the likely sounding wp_option table I found a option_name of “upload_path”. A quick query showed this was the home directory.

To save you fishing, here’s the SQL needed to set things right. Obviously select the appropriate database with “use” first!


update wp_options
set option_value='<path-to-your-wordpress-installation>/wp-content/uploads'
where wp_options.option_name='upload_path';

This is how you do it using straight SQL from the command line. If you’re using some sort of restricted web hostinig account “See your system administrator” and point them here.

Sage 2011? Line 50 with a proper database

Friday, March 5th, 2010

Today I ran in to my “old friends” Sage at a computer show; they didn’t recognise me and tried to interest me in Sage Accounting for my business. I was wearing a suit, I suppose. As you can imagine, it didn’t take long for them to catch on, after which I turned the subject to the subject of Line 50 using a proper database.

You might have got the impression I really don’t like Sage. That’s not strictly true; the issue is that I really don’t like the idea of Line 50 being sold to SMEs planning to use it for anything non-trivial. Interestingly, the people from Sage agree – at least in private. The database driven version to cure the problemhas been promised for four years, so they’re obviously aware of the issue!

So when’s it coming? Apparently in Sage 2011, due out in August 2010. “Really?” I said. “Yes, definitely. At least that’s the plan”, they said.

I pushed a bit further – would it be using mySQL as promised or would they wimp-out and use the lightweight Microsoft server. I didn’t get an answer, which confirms my fears, but even a Microsoft SQL server is better that the current arrangement.

I tried to discuss the performance issues for people upgrading to Line 50 Version 2010 with them, but I got the impression they were a bit jaded on the subject, and did a very poor job of feigning surprise.

Why is Sage Line 50 so slow?

Thursday, January 14th, 2010

As regular readers will know, I don’t think much of Sage accounting software, especially Sage Line 50. It’s fatally flawed because it stores its data in disk files, shared across a network using a file server. I suspect these.DTA files are pretty much unchanged since Graham Wylie’s original effort running under CP/M on an Amstrad PCW. There is continual talk that the newer versions will use a proper database, indeed in 2006 they announced a deal to work with mySQL. But the world has been been waiting for the upgrade ever since. It’s always coming in “next year’s” release but “next year” never comes.The latest (as of December 2009) is that they’re ‘testing’ a database version with some customers and it might come out in version seventeen.

In fact it’s in Sage’s interests to keep Line 50 running slower than a slug in treacle. Line 50 is the cheap end of the range – if it ran at a decent speed over a network, multi-user, people wouldn’t buy the expensive Line 200 (aka MMS). The snag is that Line 50 is sold to small companies that do need more than one or two concurrent users and do have a significant number of transactions a day.

So why is Line 50 so slow? The problem with Sage’s strategy of storing data in shared files is that when you have multiple users the files are opened/locked/read/written by multiple users across a network at the same time. It stands to reason. On a non-trivial set of books this will involve a good number of files, some of them very large. Networks are comparatively slow compared to local disks, and certainly not reliable, so you’re bound to end up with locked file conflicts and would be lucky if data wasn’t corrupted from time to time. As the file gets bigger and the number of users grows, the problem gets worse exponentially. The standard Sage solution seems to be to tell people their hardware in inadequate whenever timeouts occur. In a gross abuse of their consultancy position, some independent Sage vendors have been known to sell hapless lusers new high-powered servers, which does make the problem appear to go away. Until, of course, the file gets a bit bigger. Anyone who knows anything about networking will realise this straight away that this is a hopeless situation, but not those selling Sage – at least in public.

One Sage Solution Provider, realising that this system was always going to time-out in such circumstances, persuaded the MD of the company using it to generate all reports by sitting at the server console. To keep up the pretence this was a multi-user system, he even persuaded them to install it on a Windows Terminal Server machine so more than one person could use it by means of a remote session.

If that weren’t bad enough, apparently it didn’t even work when sitting at the console, and they’ve advised the customers to get a faster router. I’m not kidding – this really did happen.

The fact is that Sage Line 50 does not run well over a network due to a fundamental design flaw. It’s fine if it’s basically single-user on one machine, and I have clients using it this way. If you want to run multiple users, especially if your books are non-trivial, you need Sage 200/MMS – or a different accounting package altogether.