My personal opinion is that you are going to run into problems at some time or another because your Flash executable on the shared "M"-drive will at some time or another be in use by two or more persons at the same time and it has no way of knowing it.

This could lead to all kinds of subtle or not so subtle race conditions were your program tries to save the answers to your form data to the same file (leading to a "cannot use this file as it is already in use by someone else"-type of error if you save the answers to a single file, or two users trying to save the answers to new file with the same name whereby the second one overwrites the first one's file).

If your Flash program can guarantee to use an unique filename to save its results into, you could run a Perl-script at regular intervals to reap the newly created files, parse their contents, store the data in a database-file and delete the original files (or store them somewhere else). If this PERL-script runs at moments when no-one is inputting new data (say at night when the office is closed), you will avoid a lot of problems.

Still, of course it is only a kludge in order to avoid running a real web-cum-database-server.

Believe me, I tried all these simple solutions first too and now have come to use a web-and-database server and find new uses for it every day: e.g. you could show the results of all the queries in a dynamic webpage.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law