Since we still had your credentials, we took another look and think we finally found WHY this is happening:
I have a definitive answer now. Using the FTP credentials I was able to see that there are *two* very similar yet different WordPress instances installed.
northeast-weddingdirectory.co.uk has BD 2.2 installed and perfectnortheastwedding.co.uk (the instance "having" problems) has 3.1 installed. Both instances are configured to use the SAME MySQL database, which results in the odd behavior this user is seeing. Of course, this is an incorrect setup because the instances don't even share the same installed plugins (or versions) and they certainly shouldn't make use of the same database (and table prefix).
My understanding is that northeast-weddingdirectory.co.uk is an old site because when you try to access it, you get automatically redirected to perfectnortheastwedding.co.uk. The issue here is that the redirect is not implemented correctly and only the front page triggers the redirect. For instance, if you access http://northeast-weddingdirectory.co.uk/wp-admin/ you will see the page load (with tons of errors, by the way) and no redirection takes place. I download error logs for both domains and they both have entries with today's date meaning both instances are being accessed, probably even by Google crawlers or something, if not by real users.
Now, what this means to BD is exactly what the user is experiencing: when something accesses the old site, BD writes to the database that the current version is 2.2 (which is the plugin version installed there). Then someone access the new site and since this instance uses the same database it detects 2.2 as the 'current version' and triggers the update routine, ruining the fields setup (and maybe other stuff along the way). Then it writes 3.1 as the current version to the database. Later, someone access the 2.2 site again and the installation routine there detects an invalid version so it triggers dbDelta which resets the tables to 2.2 style.
Then, someone access the 3.1 instance... This cycle probably happens a lot during the day and results in the fields being reset a lot.
So field data is lost in two places: when the upgrade routine is incorrectly executed and when the tables are reset to 2.2 since the columns used by our current Fields API were obviously not present in 2.2.
Please advise the user to remove the entire WP setup at the old domain and leave only the front page redirection (or better, redirect the *whole* domain, not just the front page) to the new site. If he doesn't want to get rid of the old site, at least this site shouldn't be sharing the database (and table prefix) with a newer setup. Using the same database for different WP installations is plain wrong and it affects not only BD but a lot of other plugins. Even WP's core since different WP versions expect different database schemas or handle values differently.
Hope this clears this up once and for all.
Please try what my developer says and I believe this will clear up your issue.