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 Grome 808-737-6499 WebDNA Solutions mailto:ken@webdna.net http://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 Grome 808-737-6499 WebDNA Solutions mailto:ken@webdna.net http://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:
OLD PROBLEM (1997)
[WriteFile] problems (1997)
Just Testing (1997)
WebCatalog Upgrade Pricing? (1997)
Mac Programs (1998)
WebCatalog2 for NT Beta Request (1997)
RE: Subtotal help (1997)
Sum of [founditems] ? (2004)
Mixing and/or in searches (1998)
WC2b15 File Corruption (1997)
How to add commas to number displays (2004)
WCS Newbie question (1997)
problem (how to mark orders as 'opened') (1998)
Bug Report, maybe (1997)
Three new problems, maybe a fourth (1997)
Upgrading old WebCat Database Files (1997)
New Plug-in and Type 11 errors (1997)
Version number missing (was Mondo amounts of Mail [long]) (1999)
Keep away (1997)
Server slowing down. (1997)