On Thu, 13 Jun 2002, Brett Sanger wrote: > > 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.
Postgres handles this gracefully with it's "SEQUENCES" feature. After user1 calls up the form, user2 will be returned ID 12 rather than 11. So there's no possible conflict like that. > 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. No, there are just some gaps in the unique ID sequence, which is fine with me. (and would happen anyway later when some items got deleted). Brett's idea about using a bit of random data also seemed reasonable for a general case. -mark http://mark.stosberg.com/ --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
