Another way to look at it is in terms of metadata. A SQL database table is a common and convenient way to manage that metadata in the form of a table definition - including data type and NULL/NOT NULL for each data item (aka column).
But there are other ways to skin that cat (poor cat). Your script needs to accept the name of the file definition. Your script needs to use that name to lookup the ordered list of column names that file. Could be as simple as: foo.txt - defines file "foo" surname givenname middlename address1 address2 ... You can keep a directory with these files. Loop through each line of the specified file to extract the data. This solves two problems: 1) missing data and 2) mischievously added data. This is just one (low tech) idea, but the general idea remains the same. To maintain data integrity, you need a server-side definition of the data you collect. take it easy, Charlie P.S. never trust the browser! At 11:54 AM 5/26/2005 -0400, Chris Devers wrote: >On Thu, 26 May 2005, Alex Brelsfoard wrote: > > > Think of it this way: My perl script reads in all the data sent to > > it, creating a list of fields. Then I spit out the values associated > > with those fields (who cares how). But when a checkbox is NOT filled > > in, that field name is NOT sent to my script. So the list of fields > > is one field shorter than it should be. And with dynamic or otherwise > > changing field names..... yeah I'm screwed. > > > > A little clearer? > >Not really. > >It still seems to me that you need to be preserving the data in a form >that indicates what name/value pairs were received -- *especially* if >that set of pairs is dynamic. > >A simple tied hash might be able to do this just fine, but the other >ways mentioned in the last mail might be able to help even more. > >If the target format has to be CSV, you could then have a helper script >that extracts the data from the BDB / SQLite / etc storage, lays it out >in a useful CSV format (building up a set of all possible fields and >filling in blanks for any missing ones, etc), then saves that to a file. > >I still think that by storing things as CSV in the first place, you're >making this problem unnecessarily complicated. > > > >-- >Chris Devers > >_______________________________________________ >Boston-pm mailing list >Boston-pm@mail.pm.org >http://mail.pm.org/mailman/listinfo/boston-pm _______________________________________________ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
