Re: Date or time comparisons have bugs ...
This WebDNA talk-list message is from 1998
It keeps the original formatting.
numero = 16992
interpreted = N
texte = >The problem is not in your [Search] parameters, but in the fact that you>are doing a [Delete] within a [FoundItems] loop.>>I'm sure that Grant can explain this better than I can, but when you do a>search, WebCat creates its own internal list of matching items and>remembers them by their positions in the database.Okay, then in reality, WebCatalog is using the [index] position of the founditems context -- not the cartID -- to decide which records it will delete ...>[FoundItems] then loops>through each of those records, first performing the desired operations on>the first found record in the db, then on the second, etc. Having a>[Delete] inside [FoundItems] messes this up, because it changes the>position of records in your database.>>For example, say the [Search] finds records 1,2,and 6. On the first>[FoundItems] loop, record 1 is deleted. With record 1 gone, the original>record 2 becomes record 1, and every other record moves up a position>(2->1, 3->2, 4->3, etc.). So when [FoundItems] comes through looking for>record 2, it is really finding the original record 3, which may or may not>have met the search criteria. The original record 2 gets skipped altogether.Thanks Dave,Your explanation is very clear. All you're saying here is that the delete is *not* deleting records based on the cartID, but in the first step, delete is simply *flagging* the records to be deleted -- and WebCat is using the [index] values in order to identify which records are to be deleted in the *next* step of the process.Then in the next step, WebCatalog tries to identify the records to be deleted based on their indexed position. But unfortunately, each time a record is deleted, the indexed position of all the remaining records changes -- and that's what's causing my results to NOT be as I expected them.Thanks, now I understand how this works.I think this is an extremely critical piece of information!If I may make a simple suggestion to PCS so that others will not fall into the same trap as I did, I think it would be a very good thing to place a simple warning in the HTML docs, perhaps something in big bold red letters like this:WARNING!Do NOT place a delete context inside a founditems context. You will NOT get the results you expect! There are complicated technical reasons for this, so we ask you to please remember a simple rule (which will keep you out of trouble when deleting records):NEVER put a [delete] context inside a [founditems] context.ALWAYS use a [delete] context by itself when deleting records.Sincerely,Ken Grome808-737-6499WebDNA Solutionsmailto:ken@webdna.nethttp://www.webdna.net
Associated Messages, from the most recent to the oldest:
>The problem is not in your
[search] parameters, but in the fact that you>are doing a
[delete] within a
[founditems] loop.>>I'm sure that Grant can explain this better than I can, but when you do a>search, WebCat creates its own internal list of matching items and>remembers them by their positions in the database.Okay, then in reality, WebCatalog is using the [index] position of the founditems context -- not the cartID -- to decide which records it will delete ...>
[founditems] then loops>through each of those records, first performing the desired operations on>the first found record in the db, then on the second, etc. Having a>
[delete] inside
[founditems] messes this up, because it changes the>position of records in your database.>>For example, say the
[search] finds records 1,2,and 6. On the first>
[founditems] loop, record 1 is deleted. With record 1 gone, the original>record 2 becomes record 1, and every other record moves up a position>(2->1, 3->2, 4->3, etc.). So when
[founditems] comes through looking for>record 2, it is really finding the original record 3, which may or may not>have met the search criteria. The original record 2 gets skipped altogether.Thanks Dave,Your explanation is very clear. All you're saying here is that the delete is *not* deleting records based on the cartID, but in the first step, delete is simply *flagging* the records to be deleted -- and WebCat is using the [index] values in order to identify which records are to be deleted in the *next* step of the process.Then in the next step, WebCatalog tries to identify the records to be deleted based on their indexed position. But unfortunately, each time a record is deleted, the indexed position of all the remaining records changes -- and that's what's causing my results to NOT be as I expected them.Thanks, now I understand how this works.I think this is an extremely critical piece of information!If I may make a simple suggestion to PCS so that others will not fall into the same trap as I did, I think it would be a very good thing to place a simple warning in the HTML docs, perhaps something in big bold red letters like this:WARNING!Do NOT place a delete context inside a founditems context. You will NOT get the results you expect! There are complicated technical reasons for this, so we ask you to please remember a simple rule (which will keep you out of trouble when deleting records):NEVER put a
[delete] context inside a
[founditems] context.ALWAYS use a
[delete] context by itself when deleting records.Sincerely,Ken Grome808-737-6499WebDNA Solutionsmailto:ken@webdna.nethttp://www.webdna.net
Kenneth Grome
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
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...
Related Readings:
Math Problem - Format? (1997)
Webcat 2.0.1b1 bug with IE 3.01/4.0p1 (1997)
Draft Manual, Tutorial, and more (1997)
WebCommerce Security Alert! (1996)
Progress !! WAS: Trouble with formula.db (1997)
[append] and SSL (1997)
WebCat2b13MacPlugin - [math][date][/math] problem (1997)
Javascript Fields of Strawberry Roses and Green Bananas (2000)
Re:mac hack (1997)
FEW QUESTIONS (1997)
Fun with Dates - finally resolved but.... (1997)
Summing fields (1997)
Bug Report, maybe (1997)
Blog solution (2006)
Web Catalog 2 demo (1997)
practicing safe queries.. (2000)
re: How can I record purchases to a database? (1998)
Help name our technology! (1997)
Where is f2? (1997)
Searching for (field1 OR field2) AND field3 (2000)