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:
Banner Ads (2000)
[WebDNA] Calendar Examples (2019)
RE: Emailer on NT! (1998)
Nested tags count question (1997)
Date search bug (1998)
Frames and WebCat (1997)
PIXO (1997)
access denied problem (1997)
WebMerchant 1.6 and https (1997)
Fwd: Re(2): Password and Allow commands (1998)
Help with ShowNext (1998)
Major bug report on rootbeer (1997)
It just Does't add up!!! (1997)
WebCat2b13MacPlugIn - [include] doesn't allow creator (1997)
WebCat2b15MacPlugin - [protect] (1997)
Exclamation point (1997)
problems with 2 tags shakur (1997)
relational db question (2002)
Multiple Image Upload --> ImageMagick (2005)
WC2b15 File Corruption (1997)