Re: FlushDatabase Suggestion
This WebDNA talk-list message is from 1998
It keeps the original formatting.
numero = 18056
interpreted = N
texte = Yes, but it webdna is very fast from the close to the delete, is nearly instantaneous. It would be extremely and I stress extremely unlikely. They would essentially have to hit the [search db] command just as WC was inbetween processing the close and delete commands. I'd bet you can't get it to happen more than 1 in a million times. The only way to totally defeat this would be to lock out the users while the update took effect. Such as my requested added WC tags.How often would you be updating the information(performing this function)? Of course you would then want to minimize your risk by updating at a specified time. One that was at the databases lightest activity. I am currently involved in a project doing just this. The client updates the information in a primary database that is not accessed by the user when they are done they schedule the database to be update at the nearest light duty interval. At that point the next users actuates the update function.If your database is not being updated online and only via the copy function then it could benefit from a [copy path=yourdb.db&to=yourdb.db] [drop db=yourdb.db] flushes the file from ram and doesn't write it. Pat McCormick wrote:> Bob Minor wrote: > > > [copyfile path=new/yourdb.db&to=yourdb.db] > > [copyfile path=yourdb.db&to=backup/archive.db](just for protection) > > [closedatabase path/to/some.db] > > [deletefile path=yourdb.db] > > [copyfile path=path/to/some.db&to=../somefolder/archive.db] > > But hits are arriving the entire time these commands are being processed. > Immediately after receiving a closedatabase, WC could receive hits prior to > receiving the deletefile. There's an old copy loaded in RAM, aimed at blowing > away the new copy you have just written to disk, baby. (Sorry, the gun > metaphore made my testosterone gland tingle.) > > I think you have to quit WebStar & WebCat CGI, replace the db & relaunch. It > would be great if you could use a tag to flush RAM & stop processing of all WC > commands, etc., except for file manipulations, then resume full processing > after file manipulations were complete. > > -Pat
Associated Messages, from the most recent to the oldest:
Yes, but it webdna is very fast from the close to the delete, is nearly instantaneous. It would be extremely and I stress extremely unlikely. They would essentially have to hit the [search db] command just as WC was inbetween processing the close and delete commands. I'd bet you can't get it to happen more than 1 in a million times. The only way to totally defeat this would be to lock out the users while the update took effect. Such as my requested added WC tags.How often would you be updating the information(performing this function)? Of course you would then want to minimize your risk by updating at a specified time. One that was at the databases lightest activity. I am currently involved in a project doing just this. The client updates the information in a primary database that is not accessed by the user when they are done they schedule the database to be update at the nearest light duty interval. At that point the next users actuates the update function.If your database is not being updated online and only via the copy function then it could benefit from a [copy path=yourdb.db&to=yourdb.db] [drop db=yourdb.db] flushes the file from ram and doesn't write it. Pat McCormick wrote:> Bob Minor wrote: > > > [copyfile path=new/yourdb.db&to=yourdb.db] > > [copyfile path=yourdb.db&to=backup/archive.db](just for protection) > > [closedatabase path/to/some.db] > > [deletefile path=yourdb.db] > > [copyfile path=path/to/some.db&to=../somefolder/archive.db] > > But hits are arriving the entire time these commands are being processed. > Immediately after receiving a closedatabase, WC could receive hits prior to > receiving the deletefile. There's an old copy loaded in RAM, aimed at blowing > away the new copy you have just written to disk, baby. (Sorry, the gun > metaphore made my testosterone gland tingle.) > > I think you have to quit WebStar & WebCat CGI, replace the db & relaunch. It > would be great if you could use a tag to flush RAM & stop processing of all WC > commands, etc., except for file manipulations, then resume full processing > after file manipulations were complete. > > -Pat
Bob Minor
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:
purchase.log file (1997)
javascript for dynamic pulldowns? (1998)
[OT] WebDNA Family Album (2004)
Another form question (2000)
Help name our technology! (1997)
Problems with [Applescript] (1997)
RSS Feeds; basic info (2005)
PCS Frames (1997)
Email check problems (1999)
Can you do this??? and other stuff (1997)
Scientific notation to number, a solution? (2001)
Database of Tax Rates? (1997)
caching -check- (2001)
Can't add a field (1998)
NT considerations (1997)
Newbie from and old bee (1997)
WebCat b13 CGI -shownext- (1997)
Tcp connect (2002)
can't get WebDNA to display my SQL primary keys via ODBC (2003)
[ShowNext] (1997)