numero = 11624
interpreted = N
texte = >>>>>Is there a way for new records appended by WebCat 2.0 >>>>>to generate sku numbers?>>>The code I use is as follows: >>>>>A more reliable method for creating a unique record number is this: >> >>... because [cart] will create a unique number even when two or more people >>attempt to create a new record in the very same second.>The trouble I found with using a cart value for a SKU is that if a user is >adding multiple records they might use the browsers back button to return >to the add_record.tmpl. If that happens then they will entering records >with identical cart values. > >I'm not sure what the ideal technique would be as both cart and date have >their inherent drawbacks. I decided that the chances of having records >entered at the exact same second is less than the chance of someone using >their back button. Perhaps Grant can advise us or perhaps give us a true >random command or math context that we could compute with... Unless Ken, >you being the WebDNA guru that you are, have found a way around the back >button problem. Well ... I have an idea that should work every time - even if you reset the server's clock back - and it forever resolves the problem with the Back button:1- Instead of creating the new record directly from the form itself, pass all the form field values - including the hidden sku=[cart] value - to the results page.2- On the results page, put a [search] context that searches the database for the newly-created sku value.3- Use showif/hideif within a [lookup] to do one of the following (#4 or #5):4- If the [lookup] can NOT find the new sku value in the sku field of the database, append the new record to the database by using an [append] context on this page. I would also suggest that you display a message something like this to your users ... Thanks for creating a new record! If you want to create another new record, do NOT use the Back button on your web browser. Instead, click here to load a new blank form.5- If the [lookup] DOES find the new sku value in the database (only possible when the same user clicked the Back button to create this new record), do NOT append the new data. Instead, give the user a reply that says something like this ... Sorry, we cannot create this new record because you used the Back button to create a new record. Instead of using the Back button this time, please click here to create a new record.6- Please note: When you place here into your page, it does NOT cause the browser to reload the previous page - it causes the server to send that page, which means a new [cart] value will be created when the form is submitted.7- The reason I mentioned that this will work when you set your computer's clock back is because [cart] values (and also your VALUE=[DATE %Y%m%d%H%M%S] technique) are based on the server's clock ... and if you set that clock back, there's a chance that WebCat might create the same [cart] value that is has already created sometime earlier.Fortunately, using a [lookup] to check the sku value of every new record against the values in the database, this essentially prevents the same sku value from EVER being re-entered again - unless you do it manually or with another set of forms that do not have these safeguards built into them ... :)Sincerely, Ken Grome ..... ken@iav.com http://usarea.net/home.html
Associated Messages, from the most recent to the oldest:
>>>>>Is there a way for new records appended by WebCat 2.0 >>>>>to generate sku numbers?>>>The code I use is as follows: >>>>>A more reliable method for creating a unique record number is this: >>[cart]> >>... because [cart] will create a unique number even when two or more people >>attempt to create a new record in the very same second.>The trouble I found with using a cart value for a SKU is that if a user is >adding multiple records they might use the browsers back button to return >to the add_record.tmpl. If that happens then they will entering records >with identical cart values. > >I'm not sure what the ideal technique would be as both cart and date have >their inherent drawbacks. I decided that the chances of having records >entered at the exact same second is less than the chance of someone using >their back button. Perhaps Grant can advise us or perhaps give us a true >random command or math context that we could compute with... Unless Ken, >you being the WebDNA guru that you are, have found a way around the back >button problem. Well ... I have an idea that should work every time - even if you reset the server's clock back - and it forever resolves the problem with the Back button:1- Instead of creating the new record directly from the form itself, pass all the form field values - including the hidden sku=[cart] value - to the results page.2- On the results page, put a [search] context that searches the database for the newly-created sku value.3- Use showif/hideif within a [lookup] to do one of the following (#4 or #5):4- If the [lookup] can NOT find the new sku value in the sku field of the database, append the new record to the database by using an [append] context on this page. I would also suggest that you display a message something like this to your users ... Thanks for creating a new record! If you want to create another new record, do NOT use the Back button on your web browser. Instead, click [referrer]>here to load a new blank form.5- If the [lookup] DOES find the new sku value in the database (only possible when the same user clicked the Back button to create this new record), do NOT append the new data. Instead, give the user a reply that says something like this ... Sorry, we cannot create this new record because you used the Back button to create a new record. Instead of using the Back button this time, please click [referrer]>here to create a new record.6- Please note: When you place [referrer]>here into your page, it does NOT cause the browser to reload the previous page - it causes the server to send that page, which means a new [cart] value will be created when the form is submitted.7- The reason I mentioned that this will work when you set your computer's clock back is because [cart] values (and also your VALUE=[DATE %Y%m%d%H%M%S] technique) are based on the server's clock ... and if you set that clock back, there's a chance that WebCat might create the same [cart] value that is has already created sometime earlier.Fortunately, using a [lookup] to check the sku value of every new record against the values in the database, this essentially prevents the same sku value from EVER being re-entered again - unless you do it manually or with another set of forms that do not have these safeguards built into them ... :)Sincerely, Ken Grome ..... ken@iav.com http://usarea.net/home.html
Kenneth Grome
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...