Re: Database changes
This WebDNA talk-list message is from 1998
It keeps the original formatting.
numero = 16170
interpreted = N
texte = Thank your for this conversation. This is of interest to me also. I was somewhat confused about the initial upload procedure. Ken's procedure detailed in his message seemed logically correct. If it is, I also have the same concern about replacing databases on a busy server. Is there no other choice other than suspending connections until the uploads are done. My alternative was to set up a Kenlike procedure done at an off time. I would suspend connections, close the databases and FTP some new database file over and then release the server. This shouldn't take long , after which the connections can be started again. If there is another way to deal with this I like to know what it is. Thanks, RH Prouty bristol@interpage.net ------ Original Message ------>>>Whenever I make a change to a database, then use fetch to reload the >>>database file to the server, the changes are never appearant on the web >>>site. I have tried the [closedatabase] tag in a web page, and the >>>$flushdatabases command in a URL string, but cannot affectuate the >>>changes I made to the database file. >> >>Hmm. That is the correct procedure -- upload the new database, then issue a >FlushDatabases command (or embedded [flushdatabases]) should force it to >unload everything and reload from disk the next time a db is needed. > >Wait a minute, Grant, I hate to disagree with you, but I do *not* agree >with you upload procedure here. Maybe I am misunderstanding what you're >trying to explain, so please correct me if I'm wrong, but this is my >understanding ... > >Flushdatabases does not simply purge the RAM-cached data, it actually >writes all the open databases to disk *before* purging WebCat's RAM >database caches. So if you upload a new db file *before* issuing the >[flushdatabase] command (which is wha you're suggesting) the new db will >be overwritten by the older RAM-cached version. > >In other words, there is still no way to get the data out of WebCat's RAM >cache without having it written to disk, thus overwriting the newly >uploaded file. That's been a problem with WebCat all along for people who >need to replace existing databases with new ones. > >The correct procedure when uploading a new replacement db file to the >server is to perform the $flushdatabases command first, THEN upload the file. > >But this only works when no one happens to request a page that calls that >database in the meantime, because if that happens, WebCat will reload the >old db back into RAM before you're finished replacing the old db with the >new one... and then, once that old db is in RAM again, there's no way to >purge that RAM data without rewriting it to disk. > >So on a busy server, this generally means having to suspend new >connections or quitting the server in order to make absolutely sure that >your newly-uploaded db does not get overwritten by WebCat. > >Sincerely, >Ken Grome >ken@iav.com >808-737-6499 >WebDNA Solutions >http://webdna.net/ > > > >
Associated Messages, from the most recent to the oldest:
Thank your for this conversation. This is of interest to me also. I was somewhat confused about the initial upload procedure. Ken's procedure detailed in his message seemed logically correct. If it is, I also have the same concern about replacing databases on a busy server. Is there no other choice other than suspending connections until the uploads are done. My alternative was to set up a Kenlike procedure done at an off time. I would suspend connections, close the databases and FTP some new database file over and then release the server. This shouldn't take long , after which the connections can be started again. If there is another way to deal with this I like to know what it is. Thanks, RH Prouty bristol@interpage.net ------ Original Message ------>>>Whenever I make a change to a database, then use fetch to reload the >>>database file to the server, the changes are never appearant on the web >>>site. I have tried the
[closedatabase] tag in a web page, and the >>>$flushdatabases command in a URL string, but cannot affectuate the >>>changes I made to the database file. >> >>Hmm. That is the correct procedure -- upload the new database, then issue a >FlushDatabases command (or embedded
[flushdatabases]) should force it to >unload everything and reload from disk the next time a db is needed. > >Wait a minute, Grant, I hate to disagree with you, but I do *not* agree >with you upload procedure here. Maybe I am misunderstanding what you're >trying to explain, so please correct me if I'm wrong, but this is my >understanding ... > >Flushdatabases does not simply purge the RAM-cached data, it actually >writes all the open databases to disk *before* purging WebCat's RAM >database caches. So if you upload a new db file *before* issuing the >[flushdatabase] command (which is wha you're suggesting) the new db will >be overwritten by the older RAM-cached version. > >In other words, there is still no way to get the data out of WebCat's RAM >cache without having it written to disk, thus overwriting the newly >uploaded file. That's been a problem with WebCat all along for people who >need to replace existing databases with new ones. > >The correct procedure when uploading a new replacement db file to the >server is to perform the $flushdatabases command first, THEN upload the file. > >But this only works when no one happens to request a page that calls that >database in the meantime, because if that happens, WebCat will reload the >old db back into RAM before you're finished replacing the old db with the >new one... and then, once that old db is in RAM again, there's no way to >purge that RAM data without rewriting it to disk. > >So on a busy server, this generally means having to suspend new >connections or quitting the server in order to make absolutely sure that >your newly-uploaded db does not get overwritten by WebCat. > >Sincerely, >Ken Grome >ken@iav.com >808-737-6499 >WebDNA Solutions >http://webdna.net/ > > > >
RH Prouty
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:
How do I pass [cart] when user clicks back (2000)
populating a [table] (2004)
Roundup function? (1997)
Linux Install Question (2000)
all records returned. (1997)
no template caching (1997)
Protect vs Authenicate (1997)
Mac 2.1b2 speed (1997)
[CART] (1997)
replacing items in a db (2000)
Nested tags count question (1997)
RE: shrink-wrapped version out yet? (1997)
RE: Answer: WebDelivery downloads alias, not original ? (1997)
Make sure I understand this??? (1997)
RE: Formulas.db + Users.db (1997)
[WebDNA] How to generate md5 hash on linux (2009)
WebCat2b12 forgets serial # (1997)
Sendmail for intranet server (2004)
removing commas from a preformatted number (2000)
New site announcement + Showing once on a founditems (1997)