I win! A Sinclair ZX81...with...a...16K ram pack. Learned all the Z80 machine code and used it to create my first racing DB in the early '80s. I typed in all the results for Peter Walwyn, Henry Cecil, Dick Hern, Guy Harwood and a few others, taken from the form book, on that miserable plastic membrane keyboard it had and wrote another routine to produce statistics. Although I wasn't able to make much use of it at the time, it stood me in good stead for the second part of my career, about as far from horse racing as you could get, by the way, but that's another story.
And now for a cautionary tale about backing up databases. I have 250,000+ French races, scraped since 2011 and going back to 1982, in an SQL Server DB. I have a lot of routines written in T-SQL for managing the DB and for ad hoc queries that I use regularly. Because I know how easy it is to corrupt a DB with my sloppy programming, I got into the habit of backing everything up regularly. And it saved my bacon today.
I use a Mac with a Windows 7 virtual machine running Parallels on the OS X operating system. Apple's built-in Time Machine backs up OS X, including the Windows VM, every hour. My Windows VM is backed up in the cloud, also every hour, using Backblaze, which I've used for years with few problems, but I deliberately exclude my SQL databases from the Backblaze backups (the files are 2 GB+ in size, so it would be a significant drain on CPU resources, as they change every day). In the middle and on the last day of each month, I copy the SQL database to another disk, which requires stopping the SQL Server via Windows Services, I clone OS X, including the Windows VM, using Carbon Copy Cloner, into a bootable setup on a separate disk, which I test from time-to-time (no problems so far, as long as you disable Backblaze as soon as you fire up Windows in the clone - I'll go into the reasons why if anyone chooses this way of doing things).
And now for a dazzling example of my thinking-I know-it-all stupidity that occurred today. I've been promising myself for some time now that I would edit all the comments-in-running to determine pace factors and the race descriptions, which include sale details in selling (reclamé) races - which horse, how much and by whom the horse was claimed.
T-SQL allows you to have multiple algorithms in the same tab, so long as you comment out each algorithmic code using the "/*...*/" comments and only run the one you want by highlighting it. Paris-Turf doesn't have the same disciplined comments-in-running and sales reports that you have in the Racing Post. It's all very free-flowing and dependent on the style of who's writing them. Right, so I wanted to change the race description for a particular race to show that the horse was bought-in ("défendu") by the owner and not claimed (reclamé) by the current owner. This was the code I used:
/*
USE FrenchDB
UPDATE Links SET [Description] = 'A reclamer - 9.500 € - 1.600 metres - Corde a droite - Bon terrain - Temps total 1''44.67 - Reduction km 1''05.42. Adorian a ete defendu pour 12.888 €.'
WHERE RceID = 1145048
*/
Unfortunately, I didn't highlight the last line, so all 250,000+ races were updated with the same race description. If I had made no back-up provision, I would have been rightly fucked, but I was able to restore the complete DB using the last fortnightly copy (stopping SQL Server via Windows Services before I did so) and scraping the results for 13 days from the 1st November, allowing me to update the database up to today, with no problems. Sure, it took me all afternoon to do it, but compared to what I could have lost, that's nothing at all.
I have, arguably, the best French horse-racing database available today, thanks to a lot of hard work over the years. Unfortunately, this does not exonerate me from incredible idiocy when it comes to programming in T-SQL. So, other users of the facility: BE WARNED! You never really know how idiotic you can be!
Ray
www.dropbox.com
davejb 
