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:
Re:2nd WebCatalog2 Feature Request (1996)
Re:Emailer and encryption (1997)
Sorting by date (1997)
2.1 Stuff (1998)
math on date? (1997)
RE: Languages (1997)
RE: ShowNext Command (1997)
WebCatalog vs. Cold Fusion (1998)
WebCat2b15MacPlugin - [protect] (1997)
WebCat cannot handle compatible search parameters? (1997)
Emailer setup (1997)
Merging databases (1997)
ShowNext Command (1997)
Secure Server (1997)
WCS Newbie question (1997)
PDF Generation and cataloging (2002)
2.0Beta Command Ref (can't find this instruction) (1997)
WebDNA 5.0 Questions (2003)
Server Freeze (1998)
[WebDNA] OT: WebDNA Host required (2008)