[REPLACE db=my.db&eqSKUdatarq=[sku]]INV=100[/REPLACE] [INV] [/FOUNDITEMS] [/SEARCH]Use a variable to search, and then use the sku from the search results.Aloha, Olin> -----Original Message----- > From: Dave MacLeay [mailto:dave@digitalfrontier.com] > Sent: Wednesday, July 29, 1998 9:31 AM > To: WebDNA-Talk@smithmicro.com > Subject: Re: [REPLACE] inside [FOUNDITEMS] > > > 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. > > -Dave > > > > At 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:
|
[REPLACE db=my.db&eqSKUdatarq=[sku]]INV=100[/REPLACE] [INV] [/FOUNDITEMS] [/SEARCH]Use a variable to search, and then use the sku from the search results.Aloha, Olin> -----Original Message----- > From: Dave MacLeay [mailto:dave@digitalfrontier.com] > Sent: Wednesday, July 29, 1998 9:31 AM > To: WebDNA-Talk@smithmicro.com > Subject: Re: [replace] inside [founditems] > > > 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. > > -Dave > > > > At 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 --+ > > >
Olin DOWNLOAD WEBDNA NOW!
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...