It seems that many/most government surveys in the health sector are distributed in a fixed-format ASCII, often with SAS code provided to create variables out of the mess (e.g. NHAMCS values and formats).

By fixed-format ASCII I mean a file that looks like this:

0101010111239352w734    the cat jumped2432738564375
0101010111239352w734    the cat jumped2432738564375
0101010111239352w734    the cat jumped2432738564375
0101010111239352w734    the cat jumped2432738564375

With a set of instructions or (often non-machine-readable) codebook telling you the character number in each row and the number of characters of width that define each variable.

Anecdotally, I seem to have far more data errors when reading in these files (plus it takes way longer).

Are there documented stories out there of data errors that could be used to make a compelling use case to agencies to switch formats?

I'm thinking of something like the European Spreadsheet Risks Group list, but focused on this specific problem instead of spreadsheets.

2 Answers 2


I gave a talk many years ago (2008) at the joint AGU/SPD meeting on problems trying to read catalogs, but I don't know that it's directly applicable, as many of the cases were due to manually maintained files that were expected to be read by humans, not machines.

Our community does have a standard for documenting the files in a language-independant way (example), but some of the problems that I ran into was that the documentation was just flat out wrong -- the documentation was written years before, and someone changed the table format without updating the docs.

I did keep some other documentation of the issues that I ran into with trying to read catalogs, but I instead formatted it as a checklist of recommended practices, not as specific 'tales of woe'.

  • 1
    And I should add -- I wasn't able to connect to the CDC FTP site, so it's possible that the documentation formats are the same. (I've had some luck machine-reading ours though, but it's not 100% reliable)
    – Joe
    May 22, 2013 at 13:49

i agree with you that it's preferable when governments provide data in a format that does not require users to purchase proprietary software. but lobbying government statistical divisions is a lot more work than just writing the code ourselves. so i wrote the SAScii package for the R language. now sas-providing government agencies don't have to do anything. :)

click here to read about it.

click here to read my documentation.

click here to get it working on various government surveys, or you could click here to see the actual points in my united states government data scripts that it gets used.

i haven't converted nhamcs yet, but it's on my list. if you need to get bigger data into sqlite or monetdb, check out those folders on my github account for versions of SAScii that import directly into those databases and do not overload RAM on big files.

the tools are out there, you just gotta use them. ;) good luck!

  • Can you explain how you solved the problem in your package instead of simply promoting it? There is no issue with disclosed self promotion, but the answers need to explain the solutions.
    – Sklivvz
    May 22, 2013 at 13:25
  • OP asked a general question so i gave a general answer. here's a specific example: library(SAScii) ; parse.SAScii( "ftp://ftp.cdc.gov/pub/Health_Statistics/NCHS/dataset_documentation/namcs/sas/NAM93INP.TXT" ) May 22, 2013 at 13:41
  • +1 I like SAScii a lot and have used it a few times. Thanks for writing it. Better if they would just release their data in a decent format though. May 28, 2013 at 11:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.