First of all - are you settled on Access as a backend and C# as your front end?
Secondly - don't dynamically create and destroy databases and tables - this is typically a bad practice and counter productive. It looks like you will be only storing a few bytes so just keep the data. In fact, if this is literally all you will ever store you barely even really need a database - a spreadsheet would be ample.
Thirdly - that table design is typically a no-no (and is the sort of thing that requires dynamic table creation & deletion). It does not conform to first normal form and will usually lead to problems (one of which is the dynamic creation and deletion of objects).
Check out this link for an excellent overview of relational design and normalisation: http://www.tonymarston.net/php-mysql...se-design.html
If you design a permanent, normalised database you don't need to stress about creating dynamic DDL, and then creating dynamic DML to interact with it. You just need a few, fixed DML statements to insert, amend, delete and select data and you are good to go.
Poots, did you seriously just suggest using a spreadsheet over a database for storing data?!
I'm not sure what came over me - I need a shower
Seriously though - if sufficiently trivial I wouldn't use a database. Admittedly we don't know this based on the OPs information so far, but I store (for example) my personal "To do" lists etc in spreadsheets. Single table -> spreadsheet most of the time IME
if theres not 'that' much data or its pretty simple (read fixed size and compact) then don't rule out flat files, or even loading into memory as an array (possibly both if the data is needed in between sessions).
if its fixed format then reading a file at a specific offset would work.. mind you Im not certain that Access can read blocks from file at offsets.. so long since I had to resort to such tricks. I shudder to even remember the dodgy file handling tricks that used to be de-rigeur all those years ago.
just because Access has a relational db storage mechanism, it doesn't mean that the answer is always 'use a relational table'. In my books if you only have one or two tables, then unless you have a requirement for some complex data handling or filtering then a relational db is overkill.
if the data handling is largely linear then arrays, flat files are perfectly acceptable, but that quickly falls away if you need to analyse stuff.. eg find all values in range (a...b), find mean, compare film a to film b, etc.... now that changes everything a relational db would be ideal.