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 same folder) before the closedatabase command gets issued.#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.My testing leads me believe that one does not need to move and delete and copy files if one sticks with the above two assumptions, but Ken seems to disagree. I think a ruling by PCS is needed.Steve Rosenbaum steve@pop-art.com Associated Messages, from the most recent to the oldest:

    
  1. Re: Updating a database once per day - An example ( 1998)
  2. Re: Updating a database once per day - An example (bob 1998)
  3. Re: Updating a database once per day - An example (Kenneth Grome 1998)
  4. Re: Updating a database once per day - An example (Steve Rosenbaum 1998)
  5. Re: Updating a database once per day - An example (Kenneth Grome 1998)
  6. Re: Updating a database once per day - An example (Marty Schmid 1998)
  7. Re: Updating a database once per day - An example (Kenneth Grome 1998)
  8. Re: Updating a database once per day - An example (Kenneth Grome 1998)
  9. Re: Updating a database once per day - An example (Gary Richter 1998)
  10. Re: Updating a database once per day - An example (Peter Ostry 1998)
  11. Re: Updating a database once per day - An example (Kenneth Grome 1998)
  12. Re: Updating a database once per day - An example (Kenneth Grome 1998)
  13. Re: Updating a database once per day - An example (Rob Marquardt 1998)
  14. Re: Updating a database once per day - An example (Peter Ostry 1998)
  15. Re: Updating a database once per day - An example (Kenneth Grome 1998)
  16. Re: Updating a database once per day - An example (Kenneth Grome 1998)
  17. Re: Updating a database once per day - An example (Rob Marquardt 1998)
  18. Re: Updating a database once per day - An example (Rob Marquardt 1998)
  19. Re: Updating a database once per day - An example (Kenneth Grome 1998)
  20. Re: Updating a database once per day - An example (Steve Rosenbaum 1998)
  21. Re: Updating a database once per day - An example (Kenneth Grome 1998)
  22. Updating a database once per day - An example (Steve Rosenbaum 1998)
>>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.#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.My testing leads me believe that one does not need to move and delete and copy files if one sticks with the above two assumptions, but Ken seems to disagree. I think a ruling by PCS is needed.Steve Rosenbaum steve@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:

Linebreak as a delimiter in listwords? (2003) Resume Catalog ? (1997) Shownext from POST (2000) Country & Ship-to address & other fields ? (1997) Include a big block of text (1997) [newcart] (1998) Price problem (1997) WebCat2b13MacPlugin - nested [xxx] contexts (1997) Limiting user access to .tmpl files (1997) Quit revisited (1997) Not reading code (1997) purchase plugin (1996) Date Sorting (1997) NetSplat and WebCat2 (1997) quantity minimum problem (1997) WebCat2 Append problem (B14Macacgi) (1997) Date search bug (1998) C is for cookie - that's good enough for me... (2001) add vs. addlineitem (2004) Upgrade Problem.... (1998)