Re: [REPLACE] inside [FOUNDITEMS]

This WebDNA talk-list message is from

1998


It keeps the original formatting.
numero = 19175
interpreted = N
texte = It's all because you're using the devil's SKU :-)Seriously, as far as I know, that's the way it's always worked. A [search] generates it's own internal table of found items, idexed by their position in the database (row #). The [founditems] context loops through that internal table, and pulls the values from the specified row. Niether [search] nor [founditems] have any memory (term used loosely) of the state of these records at the time of the search.Since all changes are RAM-based and _instantanious_, the behaivior that you described is normal and expected.As has been discussed several times on this list, using [delete] inside [founditems] will really screw things up. Don't even think about going there.-DaveAt 3:34 PM 7/29/98, Michael Winston wrote: >2.1.6 through 3.0b4, MAC PI > >I discovered something today and I'm not sure if it's a bug or a feature: > >Let's say I have a record with SKU=666 and INV=30, > >[SEARCH db=my.db&eqSKUdatarq=666] >[FOUNDITEMS] >[INV]

>[REPLACE db=my.db&eqSKUdatarq=666]INV=100[/REPLACE] >[INV] >[/FOUNDITEMS] >[/SEARCH] > >returns: >30 >100 > >I expected: >30 >30 > >I never expected that the [REPLACE] would change my [FOUNDITEMS] results. >I thought it would replace the value in the database but leave the returned >values of my [SEARCH] untouched. This could (and has) caused quite a few >logic errors in some scripts. > >Has this been going on for long? > >Michael > >Michael Winston *By e-mail!: michaelw@dhorse.com >Internet Coordinator *By web!: http://www.dhorse.com/ >Dark Horse Comics, Inc. *By fax!: 503/654/9440 o--------------- Dave MacLeay --+ o----------- Digital Frontier --+ o--- dave@digitalfrontier.com --+ Associated Messages, from the most recent to the oldest:

    
  1. Re: [REPLACE] inside [FOUNDITEMS] (Kenneth Grome 1998)
  2. Re: [REPLACE] inside [FOUNDITEMS] (Peter Ostry 1998)
  3. Re: [REPLACE] inside [FOUNDITEMS] (Michael Winston 1998)
  4. Re: [REPLACE] inside [FOUNDITEMS] (Kenneth Grome 1998)
  5. Re: [REPLACE] inside [FOUNDITEMS] (Bob Minor 1998)
  6. Re: [REPLACE] inside [FOUNDITEMS] (PCS Technical Support 1998)
  7. Re: [REPLACE] inside [FOUNDITEMS] (Michael Winston 1998)
  8. Re: [REPLACE] inside [FOUNDITEMS] (PCS Technical Support 1998)
  9. Re: [REPLACE] inside [FOUNDITEMS] (Dave MacLeay 1998)
  10. Re: [REPLACE] inside [FOUNDITEMS] (PCS Technical Support 1998)
  11. Re: [REPLACE] inside [FOUNDITEMS] (Kenneth Grome 1998)
  12. RE: [REPLACE] inside [FOUNDITEMS] (Olin 1998)
  13. [REPLACE] inside [FOUNDITEMS] (Michael Winston 1998)
  14. Re: [REPLACE] inside [FOUNDITEMS] (Dave MacLeay 1998)
  15. RE: [REPLACE] inside [FOUNDITEMS] (Olin 1998)
It's all because you're using the devil's SKU :-)Seriously, as far as I know, that's the way it's always worked. A [search] generates it's own internal table of found items, idexed by their position in the database (row #). The [founditems] context loops through that internal table, and pulls the values from the specified row. Niether [search] nor [founditems] have any memory (term used loosely) of the state of these records at the time of the search.Since all changes are RAM-based and _instantanious_, the behaivior that you described is normal and expected.As has been discussed several times on this list, using [delete] inside [founditems] will really screw things up. Don't even think about going there.-DaveAt 3:34 PM 7/29/98, Michael Winston wrote: >2.1.6 through 3.0b4, MAC PI > >I discovered something today and I'm not sure if it's a bug or a feature: > >Let's say I have a record with SKU=666 and INV=30, > >[SEARCH db=my.db&eqSKUdatarq=666] >[founditems] >[INV]

>[REPLACE db=my.db&eqSKUdatarq=666]INV=100[/REPLACE] >[INV] >[/FOUNDITEMS] >[/SEARCH] > >returns: >30 >100 > >I expected: >30 >30 > >I never expected that the [replace] would change my [founditems] results. >I thought it would replace the value in the database but leave the returned >values of my [search] untouched. This could (and has) caused quite a few >logic errors in some scripts. > >Has this been going on for long? > >Michael > >Michael Winston *By e-mail!: michaelw@dhorse.com >Internet Coordinator *By web!: http://www.dhorse.com/ >Dark Horse Comics, Inc. *By fax!: 503/654/9440 o--------------- Dave MacLeay --+ o----------- Digital Frontier --+ o--- dave@digitalfrontier.com --+ Dave MacLeay

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:

WebDNA monitor not working (2002) How To get Some Help (2003) Banners and sort of random display (1997) [WebDNA] Grep (2009) LetterRip and WebCat (1998) Time Tracking (2003) [WebDNA] [OT] Spam reduction? (2009) NT Manual (1997) [WebDNA] unix timestamp in WebDNA (2009) RAM variables (1997) upgrade? (1997) Help name our technology! I found it (1997) Image Upload and Auto Resize? (2003) Quitting WebMerchant ? (1997) Multiple catalog databases and showcart (1997) setlineitem - textc and texte (2005) RE: WebDNA-Talk searchable? (1997) Generating unique SKU from [cart] (1997) Hierarchy of form/text/math variables (renamed thread) (2000) The Guru Speaks (1998)