Re: hidden databases
This WebDNA talk-list message is from 2000
It keeps the original formatting.
numero = 36219
interpreted = N
texte = Tell me if this is going to work on my thankyou.tpl page which is the one that appends to the database I added this code: [COPYFILE from=orders2.db&to=downloads/orders2.db]and I am planning of giving ftp access to the downloads folder to my customer. If my logic is correct, when the file is copied to the downloads folder it will no longer have the omega thingArt-----Original Message----- From: WebCatalog Talk [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf Of Kenneth Grome Sent: Wednesday, August 16, 2000 2:18 PM To: WebCatalog Talk Subject: Re: hidden databases >I was going over the archives and I found some one else had a similar >question, but it was for [writefile] >the solution was this code: >[writefile secure=f][/writefile] When webcat appends to a db, or closes or commits the db, it also changes the creator to WWW‡. That's what prevents webstar ftp from being able to 'see' the file, because webstar ftp is not a full-featured ftp server -- it cannot 'see' or download WWW‡ files like a normal ftp server can.But there's a webcat-based work-around:1- Create a separate upload folder for all your newly-uploaded db files. 2- Create a special admin template that closes the old database file, then immediately moves the newly-uploaded file to the location of the old file, thus forcing the old file to be overwritten by the new one.This technique is guaranteed to force webcat to purge the dbName.db file from its RAM cache, so when the new database file overwrites the old one, it's the NEW file that gets loaded into webcat's RAM cache.This is necessary because if you do *not* purge webcat's RAM-cached database immediately before overwriting that file on disk, then webcat will end up overwriting the new file with the *old* RAM-cached data the next time it commits its RAM-cached data to disk -- and that's not what you want at all ... ================================ Kenneth Grome, WebDNA Consultant 808-737-6499 http://webdna.net ================================------------------------------------------------------------- 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://search.smithmicro.com/ ------------------------------------------------------------- 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://search.smithmicro.com/
Associated Messages, from the most recent to the oldest:
Tell me if this is going to work on my thankyou.tpl page which is the one that appends to the database I added this code: [COPYFILE from=orders2.db&to=downloads/orders2.db]and I am planning of giving ftp access to the downloads folder to my customer. If my logic is correct, when the file is copied to the downloads folder it will no longer have the omega thingArt-----Original Message----- From: WebCatalog Talk [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf Of Kenneth Grome Sent: Wednesday, August 16, 2000 2:18 PM To: WebCatalog Talk Subject: Re: hidden databases >I was going over the archives and I found some one else had a similar >question, but it was for [writefile] >the solution was this code: >[writefile secure=f][/writefile] When webcat appends to a db, or closes or commits the db, it also changes the creator to WWW‡. That's what prevents webstar ftp from being able to 'see' the file, because webstar ftp is not a full-featured ftp server -- it cannot 'see' or download WWW‡ files like a normal ftp server can.But there's a webcat-based work-around:1- Create a separate upload folder for all your newly-uploaded db files. 2- Create a special admin template that closes the old database file, then immediately moves the newly-uploaded file to the location of the old file, thus forcing the old file to be overwritten by the new one.This technique is guaranteed to force webcat to purge the dbName.db file from its RAM cache, so when the new database file overwrites the old one, it's the NEW file that gets loaded into webcat's RAM cache.This is necessary because if you do *not* purge webcat's RAM-cached database immediately before overwriting that file on disk, then webcat will end up overwriting the new file with the *old* RAM-cached data the next time it commits its RAM-cached data to disk -- and that's not what you want at all ... ================================ Kenneth Grome, WebDNA Consultant 808-737-6499 http://webdna.net ================================------------------------------------------------------------- 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://search.smithmicro.com/ ------------------------------------------------------------- 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://search.smithmicro.com/
Arturo Vargas
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:
Founditems Add/remove graphic display problem (1999)
Safari browser and WebDNA set-cookies (2003)
E-mailer error codes (1997)
[WebDNA] Putting '&search' into URL killing all search contexts on my sites (2010)
SEARCH RESULTS (1998)
upgrading (1997)
Searching help needed (1998)
Weird problems with [SHOWIF]s (1997)
Questions (1998)
Country & Ship-to address & other fields ? (1997)
Converting native excel files (2001)
Setting up shop (1997)
Running 2 two WebCatalog.acgi's (1996)
Re1000001: Setting up shop (1997)
No Access warning when caching HTML files (1997)
format_to_days on NT (1997)
Verisigns SDK (pay flo pro) (2002)
[format xs] freeze (1997)
many-to-one problem (1998)
WebCatalog 4.0 ? (2000)