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:
Interfacing WebMerchant to www.fedex.com (1997)
Frames and WebCat (1997)
Press Release hit the NewsWire!!! (1997)
[WebDNA] What does PHP(5) has, that Webdna hasn't (2009)
& in Lookups (1997)
Showing unopened cart (1997)
Searching (2004)
Emailer port change (1997)
PIXO (1997)
multi-paragraph fields (1997)
pull downs (1997)
Bcc in sendmail tag (2000)
[SearchString] usage (1997)
[OT] Linux -> Winderz (2005)
[replaceChars] would be nice ... (1997)
Preserving file creation dates on [copyfile] (2007)
Friendly , quick 'security' check, please (2003)
Stumpted Again (1997)
WCf2 and nested tags (1997)
Dark Horse Comics success story (1997)