Re: Multithreading of [replace]
This WebDNA talk-list message is from 1999
It keeps the original formatting.
numero = 23110
interpreted = N
texte = >Now that I've made all these comments, I have an even faster solution. The >fact of the matter is that you don't need the search context at all. >Therefore I would get rid of it completely. You can perform the same tasks >shown above with a single replace and a single lookup, like this: > >[replace >append=t&db=carts.db&eqCARTdata=[cart]&allcase=t]cart=[cart]&date=[date >%Y/%m/%d]&firstpage=[lookup >db=carts.db&value=[cart]&lookinfield=cart&returnfield=firstpage¬found=[thisu >r >l]] ]&lastpage=[thisurl][/replace]If the reason for doing all this is for on-the-fly generation of information on the invoice page I would pass the data needed in the URI:s or hidden fields in forms, thus avoiding all writing/reading to dbs.If I also wanted even more information for analysis later I would append this information to I file (not db) and as often as I wanted process this file.If I really, really had to stick with the original db solution I would split that db into 10 different ones and store visitor 1 in db 1, visitor 2 in db 2 and so on. The info of which db a visitor belongs to I would pass in the URI. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Christer Olsson Stora Nygatan 21 Phone +46 40 791 50 Ljusa Ideer AB S-211 37 Malmoe Fax +46 40 97 99 77 Sweden http://www.ljusaideer.se
Associated Messages, from the most recent to the oldest:
>Now that I've made all these comments, I have an even faster solution. The >fact of the matter is that you don't need the search context at all. >Therefore I would get rid of it completely. You can perform the same tasks >shown above with a single replace and a single lookup, like this: > >[replace >append=t&db=carts.db&eqCARTdata=
[cart]&allcase=t]cart=
[cart]&date=[date >%Y/%m/%d]&firstpage=[lookup >db=carts.db&value=
[cart]&lookinfield=cart&returnfield=firstpage¬found=[thisu >r >l]] ]&lastpage=
[thisurl][/replace]If the reason for doing all this is for on-the-fly generation of information on the invoice page I would pass the data needed in the URI:s or hidden fields in forms, thus avoiding all writing/reading to dbs.If I also wanted even more information for analysis later I would append this information to I file (not db) and as often as I wanted process this file.If I really, really had to stick with the original db solution I would split that db into 10 different ones and store visitor 1 in db 1, visitor 2 in db 2 and so on. The info of which db a visitor belongs to I would pass in the URI. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Christer Olsson Stora Nygatan 21 Phone +46 40 791 50 Ljusa Ideer AB S-211 37 Malmoe Fax +46 40 97 99 77 Sweden http://www.ljusaideer.se
Christer Olsson
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:
Sku numbers (1997)
Bad cookie (1998)
Emailer again & again (1997)
Posting form data to a popup (2004)
PIXO support (1997)
Server Load (2000)
[append] and SSL (1997)
Feature Request: ! character bug correct in [showif [variable]=] (2000)
Help needed! (1998)
billing system (2003)
Emailer (1998)
Building Calendars (1997)
webcatalog [date] bug...not (1999)
Emailer 1.0.2 Conflicts? (1998)
WebCat2b13MacPlugin - [math][date][/math] problem (1997)
Notepad problems (1998)
[OT] test (2002)
return missing item (was:WebCat Sales) (1997)
Hard Questions ? (1997)
emailer setup (1997)