Re: Updating a database once per day - An example
This WebDNA talk-list message is from 1998
It keeps the original formatting.
numero = 17997
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 samefolder) before the closedatabase command gets issued.#2 the database contents get updated manually, they never gets updatedthrough WebCatalog- thus, when one issues the [CLOSEDATABASE my.db] command, no changes getwritten to diskbecause WebCatalog does not think there any changes.My testing leads me believe that one does not need to move and delete andcopy files if one sticks with the above two assumptions, but Ken seems todisagree. I think a ruling by PCS is needed.Steve Rosenbaumsteve@pop-art.com
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 samefolder) before the closedatabase command gets issued.#2 the database contents get updated manually, they never gets updatedthrough WebCatalog- thus, when one issues the [CLOSEDATABASE my.db] command, no changes getwritten to diskbecause WebCatalog does not think there any changes.My testing leads me believe that one does not need to move and delete andcopy files if one sticks with the above two assumptions, but Ken seems todisagree. I think a ruling by PCS is needed.Steve Rosenbaumsteve@pop-art.com
Steve Rosenbaum
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:
Re1000001: Setting up shop (1997)
WebTen and WebCat (1997)
Whats wrong with this code? (1998)
Bug Report, maybe (1997)
hm. (2002)
[WebDNA] OT: just poking (2010)
Re:2nd WebCatalog2 Feature Request (1996)
Show shoppingcart after remove last item (1997)
Frames and WebCat (1997)
RE: type 2 errors with ssl server (1997)
Cross-platform file locations? (2000)
RE: IIS 4 (1998)
Date format problems (1997)
OT - Need A Good Address Parser (2000)
Showing unopened cart (1997)
Why don't Typhoon & Firesite work together? (and webcat) (1998)
Banners (1997)
WebCat for mass emailings (1997)
[WebDNA] HTML/OS vs. WebDNA ? (2008)
RAM variables (1997)