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:

[quantity] within formulas (1997) NT Version on IIS 4.0 (1997) RE: Automatic thumbnail images (1998) Problem with empty form-variables in [search] (1998) OT: zipcodes (2002) Windows-based Code Editor (2002) NT or Mac (1997) ampersand (1998) Setting up shop (1997) Removing [showif] makes a big difference in speed (1997) Re:Change WebDNA-Talk Mail due to no digest for 1wk (1997) WC 4? (2001) Emailer Chokes on bad address (1997) Search for starts with and ends with? (2003) What is WebDNA (1997) 2.1.1 bug (ORDERFILE/SHOWIF/LINEITEMS) (1998) Multiple download orders of the same product? (1997) SHOWIF/HIDEIF empty fields (2005) Persistant Connections (2000) UPDATE PROBLEM (1997)