Re: Updating a database once per day - An example
This WebDNA talk-list message is from 1998
It keeps the original formatting.
numero = 18001
interpreted = N
texte = >>>I've been following this thread for a while now and I like Ken's technique>>>for handling the data swap - I only have one concern. What happens if your>>>[deletefile] calls out a db that has recently been closed by WebCat because>>>of a RAM limit?>>>>It still deletes the file, and that's all that matters.>>>>>Are you taking steps to make sure the file IS in RAM before>>>you delete the disk-based copy?>>>>No, because it doesn't have to be in RAM beforehand.>>>>The critical point is simply to make sure that from the instant it is>>purged from the RAM cache, it *stays purged* -- until WebCat has moved the>>new db file into position. The [delete] simply gets rid of the file on>>disk, so there's no chance of it being reloaded into RAM again ... until>>AFTER the new file is in position ... :)>>>>Wait!>Since I started this thread & I articulated two assumptions for this scenario:>>#1the new database file is in position (with the same file name in the same>folder) before the closedatabase command gets issued.I don't remember you articulating this assumption. Which message was this in?Anyways, I'm just trying to explain that it is *not* correct procedure to replace an existing WebCat db file without first closing the database in one way or the other.In fact, you should NEVER replace an existing WebCat db file without closing it first ... or the next time WebCat receives a $flushdatabases command or [closedatabase] or [commitdatabase] or if someone simply quits it, WebCat will overwrite the newer disk file with the older RAM cache and you'll be right back where you started.>#2 the database contents get updated manually, they never gets updated>through WebCatalog - thus, when one issues the [CLOSEDATABASE my.db]>command, no changes get written to disk because WebCatalog does not think>there any changes.Steve, I think you're forgetting the whole point of using the [closedatabase] tag. In this situation we are NOT using [closedatabase] to write the RAM-cached data to disk -- we are using it to purge the RAM cache -- so the OLD data still held in the cache doesn't end up overwriting the NEW data file later.Sincerely,Ken Grome808-737-6499WebDNA Solutionsmailto:ken@webdna.nethttp://www.webdna.net
Associated Messages, from the most recent to the oldest:
>>>I've been following this thread for a while now and I like Ken's technique>>>for handling the data swap - I only have one concern. What happens if your>>>
[deletefile] calls out a db that has recently been closed by WebCat because>>>of a RAM limit?>>>>It still deletes the file, and that's all that matters.>>>>>Are you taking steps to make sure the file IS in RAM before>>>you delete the disk-based copy?>>>>No, because it doesn't have to be in RAM beforehand.>>>>The critical point is simply to make sure that from the instant it is>>purged from the RAM cache, it *stays purged* -- until WebCat has moved the>>new db file into position. The
[delete] simply gets rid of the file on>>disk, so there's no chance of it being reloaded into RAM again ... until>>AFTER the new file is in position ... :)>>>>Wait!>Since I started this thread & I articulated two assumptions for this scenario:>>#1the new database file is in position (with the same file name in the same>folder) before the closedatabase command gets issued.I don't remember you articulating this assumption. Which message was this in?Anyways, I'm just trying to explain that it is *not* correct procedure to replace an existing WebCat db file without first closing the database in one way or the other.In fact, you should NEVER replace an existing WebCat db file without closing it first ... or the next time WebCat receives a $flushdatabases command or
[closedatabase] or
[commitdatabase] or if someone simply quits it, WebCat will overwrite the newer disk file with the older RAM cache and you'll be right back where you started.>#2 the database contents get updated manually, they never gets updated>through WebCatalog - thus, when one issues the [CLOSEDATABASE my.db]>command, no changes get written to disk because WebCatalog does not think>there any changes.Steve, I think you're forgetting the whole point of using the
[closedatabase] tag. In this situation we are NOT using
[closedatabase] to write the RAM-cached data to disk -- we are using it to purge the RAM cache -- so the OLD data still held in the cache doesn't end up overwriting the NEW data file later.Sincerely,Ken Grome808-737-6499WebDNA Solutionsmailto:ken@webdna.nethttp://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:
[WebDNA] Press Release (2008)
Dumb Question about Docs (1997)
corrupted images (2002)
[WebDNA] Displaying age (2010)
WebCat2 - Getting to the browser's username/password data (1997)
[WebDNA] unique words (2009)
b12 cannot limit records returned and more. (1997)
Sort Order on a page search (1997)
[OT] Friday Time Waster (2003)
Excuse me for a second (2000)
Re(2): SSL, WebSTAR, WebCatalog (1998)
SV: Mass Mail (2000)
gateway application timeouts (1998)
Search/sort in URL Was: GuestBook example (1997)
problem serving foreign languages text (1997)
process SSI (1998)
Where is f2? (1997)
submit a form using javascript in netscape (2001)
Not processing (2005)
(2001)