Re: WebCAT has the devil in it!
This WebDNA talk-list message is from 2003
It keeps the original formatting.
numero = 54066
interpreted = N
texte = On 11/13/03 1:34 PM, "Scott Anderson"
wrote: >> It appears that when WebCAT went to do a safe write, that it saw a >> tempDB >> already there and as such created a new one with an incremented number. > This is correct. >> However, this time, instead of deleting the tmp file after the safe >> write it >> left it. > What is supposed to happen is that the original db file gets renamed to > something like "my.db-oRiGiNaL-". If the rename succeeds, then the new temp > db file is renamed to the original db name. And if that rename succeeds, > the "my.db-oRiGiNaL-" is deleted. Bingo, there was a file created by WebCAT in there with the original in the name... Causing the continuing failure. > I suspect that an 'very' untimely crash occurred during the rename process > (which would be pretty rare) and left a dangling "...-oRiGiNaL-" file. This > would prevent the first rename step from completing, and would lead to the > new incremented tmp file being left in place. IF this happens, delete the > '...-oRiGiNaL-' file, backup your original db file, and replace it with the > tmp db file with the largest increment. Interestingly enough, the true original file (something.db) had all the updated data as the largest increment. Which would be slightly different than you mention but still worked for us. > If this happens fairly frequently on your server, the only option that I see > would be for you to turn off that Safe Write feature. I would also make > sure that error logging is enabled, and check the error logs to track and > fix templates bugs. You can also enable the 'Technical Support Information' > pref. This will log every hit that comes into the server to a file called > WebCatalog.debug. Using this file, you have a good chance of tracking the > last template requested before each crash. You can then examine that > template code for any errors. That debug log can get pretty big, very fast, > so only enable it when you are able to spend some time examining the > entries. If resolving template bugs improves engine stability, then you can > try re-enabling the SafeWrite pref. This assumes that the 'crash' had anything to do with webcat, which I do not believe it did. Certainly untimely and for the record the one and only occurrence of this I have ever seen! > Also, it is always a good idea to perform frequent backups of your db files. We do, and thankfully I coded those backups by exact name and not by directory. Imagine that ..lol > We will continue to improve the 'Safe Write' code for future releases, as it > is a beneficial feature. Sounds great Scott, but one hanging question... If I do turn it off, which I may not, what ultimately am I losing in functionality? PS... I would wager that any developer in my position would have probably rather WebCAT stop duplicating the files after a certain number(perhaps a pref setting). The uncontrollable nature of this scared me...jmho Alex J McCombie New World Media Chief Information Officer Box 124 888/892.6379 MartVille, NY 13111 Alex@NewWorldMedia.com http://OurClients.com Interface Designer WebDNA Programmer Database Designer ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
Associated Messages, from the most recent to the oldest:
On 11/13/03 1:34 PM, "Scott Anderson" wrote: >> It appears that when WebCAT went to do a safe write, that it saw a >> tempDB >> already there and as such created a new one with an incremented number. > This is correct. >> However, this time, instead of deleting the tmp file after the safe >> write it >> left it. > What is supposed to happen is that the original db file gets renamed to > something like "my.db-oRiGiNaL-". If the rename succeeds, then the new temp > db file is renamed to the original db name. And if that rename succeeds, > the "my.db-oRiGiNaL-" is deleted. Bingo, there was a file created by WebCAT in there with the original in the name... Causing the continuing failure. > I suspect that an 'very' untimely crash occurred during the rename process > (which would be pretty rare) and left a dangling "...-oRiGiNaL-" file. This > would prevent the first rename step from completing, and would lead to the > new incremented tmp file being left in place. IF this happens, delete the > '...-oRiGiNaL-' file, backup your original db file, and replace it with the > tmp db file with the largest increment. Interestingly enough, the true original file (something.db) had all the updated data as the largest increment. Which would be slightly different than you mention but still worked for us. > If this happens fairly frequently on your server, the only option that I see > would be for you to turn off that Safe Write feature. I would also make > sure that error logging is enabled, and check the error logs to track and > fix templates bugs. You can also enable the 'Technical Support Information' > pref. This will log every hit that comes into the server to a file called > WebCatalog.debug. Using this file, you have a good chance of tracking the > last template requested before each crash. You can then examine that > template code for any errors. That debug log can get pretty big, very fast, > so only enable it when you are able to spend some time examining the > entries. If resolving template bugs improves engine stability, then you can > try re-enabling the SafeWrite pref. This assumes that the 'crash' had anything to do with webcat, which I do not believe it did. Certainly untimely and for the record the one and only occurrence of this I have ever seen! > Also, it is always a good idea to perform frequent backups of your db files. We do, and thankfully I coded those backups by exact name and not by directory. Imagine that ..lol > We will continue to improve the 'Safe Write' code for future releases, as it > is a beneficial feature. Sounds great Scott, but one hanging question... If I do turn it off, which I may not, what ultimately am I losing in functionality? PS... I would wager that any developer in my position would have probably rather WebCAT stop duplicating the files after a certain number(perhaps a pref setting). The uncontrollable nature of this scared me...jmho Alex J McCombie New World Media Chief Information Officer Box 124 888/892.6379 MartVille, NY 13111 Alex@NewWorldMedia.com http://OurClients.com Interface Designer WebDNA Programmer Database Designer ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
Alex McCombie
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:
populating a table from multiple cookies (2005)
Emailer errors - repost (2000)
WebCat2b13MacPlugIn - [include] doesn't allow creator (1997)
WebCatalog Technical Reference (1997)
Intermitent problem using [referrer] (1997)
Server Creation - vendors (2005)
Trouble with formula.db + more explanation (1997)
Not really WebCat- (1997)
WebCatalog dying in WebTen Revisited (1998)
Exclude by date - multiple (1997)
[showif [getcookie otherDomain]=yes] inside a [TCP connect] will work? (2000)
Dummy Credit Card Number for debug? (1997)
How To question on setting up downloads (1997)
Okay, I give up... (1999)
Looking for WebDNA 3.08 MAC (2003)
Multiple Newcarts (1996)
Sku numbers (1997)
Problems with [Applescript] (1997)
Here's how to kill a Butler Database. (1997)
Logging purchases (1997)