“The issue occurred because some files containing positive test results exceeded the maximum file size that takes these data files and loads then into central systems, officials said.”
c) All those Excel references in the news seem to postdate (at time of writing) speculation on Excel in IT-heavy forums like this.
While I can believe the Excel conjecture is correct, I wish people would stop referencing it like it's a proven fact, or provide an authoritative source for the Excel claim.
I hope you're right, but most reports do at least mention "exceeding maximum file size". That seems like a fairly basic error: what reasonable (national-scale) data storage formats would have an arbitrary file size limit?
A normalised SQL DB will have zero redundancy. It would also easily handle these data set sizes. The only reason Excel was chosen was because clearly some clerk just felt more familiar with the tool and didn't have the experience to know better.
The reality is though for storing this kind of relational data -- it's a solved problem -- SQL would have been the correct tool to employ.
We’ve actually had a similar issue in the US with some Electronic Initial Case Report documents (to be clear, we mostly rely on Electronic Lab Results-ELR rather than eICR in the US to count COVID numbers, so this hasn’t resulted in an under-count)
Rather than be a problem with the database having arbitrary file size limits, it actually was a problem with file size limits within network intermediaries. In most cases, the issue is less the limit, and more that the files themselves were too large because of how they were created. I don’t think this is the same issue as the UK (I don’t think they are using the eICR standard there yet), but it’s an example of how you could have a problem with file size limitations without storing data in Excel.
It's probably more the web server configured to only allow x MB maximum for file uploads. Or since the government has been shown to be incompetent, maybe it's the maximum size for email attachments..
Particularly, they reckon they were using the older XLS rather than XLSX format with the lower 65000 row limit - although that seems more like a deflection from the fact functionality limits weren't properly handled, tested or designed for.
23 comments
[ 3.2 ms ] story [ 56.2 ms ] thread> The reason was apparently that the database is managed in Excel and the number of columns had reached the maximum.
> The files have now been split into smaller multiple files to prevent the issue happening again.
Wow
a) The Twitter link is referencing the Daily Mail. https://www.dailymail.co.uk/news/article-8805697/Furious-bla...
b) The Mail does not source it's claim.
c) All those Excel references in the news seem to postdate (at time of writing) speculation on Excel in IT-heavy forums like this.
While I can believe the Excel conjecture is correct, I wish people would stop referencing it like it's a proven fact, or provide an authoritative source for the Excel claim.
I hate to be that guy, but...
I thought people had somehow done some math on #cases/sheets to arrive at an obvious-but-not-to-me fact :)
The reality is though for storing this kind of relational data -- it's a solved problem -- SQL would have been the correct tool to employ.
Rather than be a problem with the database having arbitrary file size limits, it actually was a problem with file size limits within network intermediaries. In most cases, the issue is less the limit, and more that the files themselves were too large because of how they were created. I don’t think this is the same issue as the UK (I don’t think they are using the eICR standard there yet), but it’s an example of how you could have a problem with file size limitations without storing data in Excel.
https://twitter.com/MaxCRoser/status/1313046638915706880
Particularly, they reckon they were using the older XLS rather than XLSX format with the lower 65000 row limit - although that seems more like a deflection from the fact functionality limits weren't properly handled, tested or designed for.