I had a request to do a simple voting script that captures voting results and contestant personal details in ASP. So I wrote it to write to a flat file in txt format. When a friend knew about it, he gave me that disapproving look and asked what if 10 people tried to access it at once? Well, reality check, that contest only has like 3 questions and only 5 fields in personal details. If the file was opened by another user, user might get an error message and will attempt to try to submit again right? So I don't think it's a big issue. But I could be wrong. Isn't flat file appropriate for this purpose or should i just go heavy duty and write to a SQL database? It's not like they're going to do any heavy duty queries. An Excel auto-filter could do the trick. Comments?

To most people, getting an error message is unacceptable. Telling end users they'll have to put up with this every now and then, and to just hit back and try again, isn't going to be very popular.

Flat files can be a workable solution sometimes, but this usually requires a single process to have constant access to the file and other processes that need it to make requests and have a little conversation between the software to get at the data in the file, or add more to it. Because of the way IIS assigns threads to handle requests, this isn't a good option here.

Excel could be enough to analyze the data, and you might even be able to use the ODBC Excel driver with a long timeout, so that if you need to add data but the file is locked, you'll just wait until the file is closed for your turn. Since adding a record won't take much time, the user wno't ever have to wait for ages. And the driver should have its own threading system that will be compatible with IIS.

Or, if your server's security allows, use the filesystem as a database. Create a new folder for each poll, and a new file within the right folder for each user session. Then list all the files in any particular folder to reap the responses.

Thanks Forrest. Sometimes I used CreateTextFile with timestamps so that unique text files are generated for every entry. At the end of the day, I'll just merge them together into 1 big txt file, which can be converted into Excel format. That seems to work fine and won't overwork the server I suppose. It hasn't break yet so far..

You might want to add to the timestamp either a random number or the calling IP address or something, to be completely thread safe ... and so when somebody frowns you can say "I've already thought of that."

I learned that you can open a command prompt and type "Copy *.* somefile.text" to append the contents of all the files in a directory into one.

You can also work with the file-system in ASP, and be able to link to each individual vote or a whole directory.

Depending of what web site language (jsp/asp/php) you use, you could take a look on sqlite (http://www.sqlite.org).
It's embedded in php5, and it allows you to create a relationnal SQL database stored in a file on your server.
You can simply copy the file elsewhere, and use the sqlite tools on any comp to retrieve the results.

You would have a file, easily movable, easy to backup too, but with a locking mechanism and computing ability.

Article about sqlite + asp:
http://www.aspfree.com/c/a/Database/...abase-Storage/

sqlite+php
http://www.php.net/manual/en/ref.sqlite.php

and about java/jsp:

There are Java bindings to SQLite native library provided as a JDBC driver.

from http://en.wikipedia.org/wiki/SQLite#Language_bindings

There is nothing wrong with a flat file database, just a MySQL one is a lot more fun to use and has a lot more features.
There 3D and a lot more space effective.

Just use file locking. There won't be any errors. I have had an AJAX chat site running since about 1997 which uses a single flat file of 20 lines. New posts are added at the top, old ones fall off the bottom. Never a problem - even with a hundred users at a time