> In the case where the form is being used to insert some data into a > database, here's an easy trick that I like to use: > > In the form display run mode, select the next available unique ID for > the item that will be it's primay key. When you submit the form, you > simply have to check to see if you've already inserted something with > the same ID (which your database may actually prevent you from doing > anyway).
Doesn't that fail messily if you have concurrent submissions? user1 calls up form to submit, it sees that the DB has IDs 1-10 filled, so drops ID-11 in the form. user2 calls up form to submit, it sees that the DB has IDs 1-10 filled, so it drops ID-11 in the form. user1 submits, taking slot 11. user2 submits, get bounced because id-11 is used. Unless you mean that you put in a blank "holding" item in the database, which means you're doing an insert on an otherwise informational page (plus you have to worry aobut treating NOT NULL and UNIQUE fields correctly). Seems that would clutter your db with bad entries when users don't commit to actually submitting their forms. Unless your db supports a next_available() routine that doesn't clog the database and doesn't return the same value twice. What would the timeout on that be? --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
