Re: Updating a database once per day - An example

This WebDNA talk-list message is from

1998


It keeps the original formatting.
numero = 17988
interpreted = N
texte = >At 13:30 Uhr -1000 31.05.1998, Kenneth Grome wrote: > >>>I believe if you perform [closedatabase] AFTER you moved the new one in, >>>there will be no chance to open the old one - it simply does not exist >>>anymore. >> >>I hate to disagree, but this last recommendation is wrong ... >> >>You *must* close the database FIRST -- because closing it, or using >>[flushdatabases], or quitting WebCatalog -- are the only ways to purge the >>old data from RAM. And you *must* purge the RAM cache or that RAM-cached >>data will overwrite the newer disk file at the next [closedatabase] or >>[flushdatabases] or [quit]. >> >> (this is from a different mail) >>[deletefile test.db] >>[closedatabase test.db] >>[movefile path=spareFolder/test.db&to=test.db] > > >I see. But it does not look logical in my understanding, because the manual >states: >Putting [CLOSEDATABASE FileName] in your template will cause the specified >database file (or full path) to be written and closed.Yes, the manual should probably go into a little more detail to say specifically that the cached data gets written to the db file on disk *if* that file is still there ... but if the file has been moved or deleted then [closedatabase] does NOT write anything to disk.Sorry, I don't write the manuals, I just use the software ... :)>Second, do you have a special reason to use [deletefile]? Moving the new >file will overwrite the old one anyway.Actually I have a very good reason for using [deletefile]. After you purge the data from RAM by using [closedatabase] you do *not* want that same data to be reloaded again before the [movefile] has had a chance to replace the current db file with the new one. The only way to prevent this with 100% certainty is to move that file out of the folder BEFORE the [closedatabase]. You can use [movefile] or [deletefile] to do this, I just happened to use [deletefile] in my example.>I interpret [closedatabase] as a write-command (according to the manual). >So far I know file operations on the mac have absolute priority and nobody >should be able to read a file during a write-command.This is correct, but there's nothing that can stop another thread from reloading the cache in between [closedatabase] and [movefile] unless you actually get rid of the file before [closedatabase] is issued. It's those *other threads* you have to think about in this situation ... :)>And immediately >follows [movefile], which is a write-command either in this case. So I >think there is no chance for a user to open the database again until the >two commands are finished. Is this wrong - is your code more secure?Yes this is wrong, and yes, my code is more secure ... :)The main thing you must be aware of is that there are several threads that can do different things in WebCatalog, so you must deal with the possibility that another thread might actually start a search before YOUR thread has finished everything it's supposed to do.And if another thread happens to start a search in between your [closedatabase] and [movefile], then the old data will get cached again and your new data will never get loaded into cache, because that cache already has the old data in it, and that data will overwrite your new db file the first chance it gets.So ... the best technique is to issue [closedatabase] *after* first getting rid of the db you're going to close. Then if another thread tries to come in and reload that same old data, it cannot -- because the data won't be there to reload! :)Sincerely, Ken Grome 808-737-6499 WebDNA Solutions mailto:ken@webdna.net http://www.webdna.net 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)
>At 13:30 Uhr -1000 31.05.1998, Kenneth Grome wrote: > >>>I believe if you perform [closedatabase] AFTER you moved the new one in, >>>there will be no chance to open the old one - it simply does not exist >>>anymore. >> >>I hate to disagree, but this last recommendation is wrong ... >> >>You *must* close the database FIRST -- because closing it, or using >>[flushdatabases], or quitting WebCatalog -- are the only ways to purge the >>old data from RAM. And you *must* purge the RAM cache or that RAM-cached >>data will overwrite the newer disk file at the next [closedatabase] or >>[flushdatabases] or [quit]. >> >> (this is from a different mail) >>[deletefile test.db] >>[closedatabase test.db] >>[movefile path=spareFolder/test.db&to=test.db] > > >I see. But it does not look logical in my understanding, because the manual >states: >Putting [CLOSEDATABASE FileName] in your template will cause the specified >database file (or full path) to be written and closed.Yes, the manual should probably go into a little more detail to say specifically that the cached data gets written to the db file on disk *if* that file is still there ... but if the file has been moved or deleted then [closedatabase] does NOT write anything to disk.Sorry, I don't write the manuals, I just use the software ... :)>Second, do you have a special reason to use [deletefile]? Moving the new >file will overwrite the old one anyway.Actually I have a very good reason for using [deletefile]. After you purge the data from RAM by using [closedatabase] you do *not* want that same data to be reloaded again before the [movefile] has had a chance to replace the current db file with the new one. The only way to prevent this with 100% certainty is to move that file out of the folder BEFORE the [closedatabase]. You can use [movefile] or [deletefile] to do this, I just happened to use [deletefile] in my example.>I interpret [closedatabase] as a write-command (according to the manual). >So far I know file operations on the mac have absolute priority and nobody >should be able to read a file during a write-command.This is correct, but there's nothing that can stop another thread from reloading the cache in between [closedatabase] and [movefile] unless you actually get rid of the file before [closedatabase] is issued. It's those *other threads* you have to think about in this situation ... :)>And immediately >follows [movefile], which is a write-command either in this case. So I >think there is no chance for a user to open the database again until the >two commands are finished. Is this wrong - is your code more secure?Yes this is wrong, and yes, my code is more secure ... :)The main thing you must be aware of is that there are several threads that can do different things in WebCatalog, so you must deal with the possibility that another thread might actually start a search before YOUR thread has finished everything it's supposed to do.And if another thread happens to start a search in between your [closedatabase] and [movefile], then the old data will get cached again and your new data will never get loaded into cache, because that cache already has the old data in it, and that data will overwrite your new db file the first chance it gets.So ... the best technique is to issue [closedatabase] *after* first getting rid of the db you're going to close. Then if another thread tries to come in and reload that same old data, it cannot -- because the data won't be there to reload! :)Sincerely, Ken Grome 808-737-6499 WebDNA Solutions mailto:ken@webdna.net http://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:

Flash Stores (2003) WebCat2b14MacPlugIn - [include] doesn't hide the search string (1997) expired beta (1997) Some ThankYou page problems (1997) using showpage and showcart commands (1996) Multiple prices (1997) Protect and Serve (1999) Attention all list readers (1997) Frames and WebCat (1997) many-to-one problem (1998) [HIDEIF] inside [FOUNDITEM] (1997) X etc.... (1999) using showpage and showcart commands (1996) Re:mac hack (1997) WebCat2 several catalogs? (1997) [WebDNA] Accepting Payments on Site (2013) how to do multiple prices/item? (1998) SQL - Output into file (2004) Append again (1999) Robert Minor duplicate mail (1997)