Re: Database Updates
This WebDNA talk-list message is from 1997
It keeps the original formatting.
numero = 13267
interpreted = N
texte = >I posted a related message about this last week. The single answer I got did >not quench my thirst for a better solution. > >I have enabled several store fronts with the WebCatalog acgi. I now want to >figure out an easy means of updating the various catalog.txt >database files.Well, do you have to do this one at a time or all at once?>Most clients will be maintaining these in locally operated database files and >exporting updates to me.Okay, then it looks like you're going to want to update these databases manually, one at a time.>I will then use Timbuktu to place them on the server.No problem ... but you're getting into a situation here that requires planning and an understanding of how WebCat works with RAM data vs. disk-based data.>However, it seems that >the only way I can do this is to effectively close and update EVERY database >file that WebCatalog has opened via the WebCatalog admin interface.That's right, before you replace and WebCat database file manually, you *MUST* make sure that that database data is purged from WebCat's RAM partition. If you fail to perform this step, you will soon find that your newly-updated data file get's overwritten by WebCat's RAM data - which is not what you really want to happen ... :)>Is there not a better way to close a single database and replace it with a >newer version without affecting over a dozen other database files?Yes, of course, that's what the [closedatabase] tag is for. Using the [closedatabase] tag you can close every database - individually. It's in the manual ...>Also, I seem to recall some discussion that the acgi version was not taking >manually entered updates. I remember one client trying to manually update the >ads.db and any new items he entered did not show up.This has nothing to do with the CGI vs. the plugin, it has to do with the user NOT understanding how to properly update his data files manually. That client simply failed to purge the RAM copy of his database file from WebCat's RAM partition before replacing the database on disk first.This is a common mistake for beginners when they choose to maintain their databases with other programs and update those databases manually - by replacing database files on the server - instead of making changes thru WebCatalog.>Is there something special that has to be done in >order to get WebCatalog to note that a change to the RAM-based file has been >made by a manually entered item?Yes, you have to close that database BEFORE you replace that data file on disk. Close it with the [closedatabase] tag or the $flushdatabases command, but do it immediately before replacing the data file on disk.What's more, you have to be very fast when doing this, especially if your database is being accesses a lot ... because even though using the [closedatabase] tag or the $flushdatabases command closes the database file and purges WebCat's RAM for that database, the same database will be loaded into RAM again the very next time someone requests info from that database.Therefore, if you really want to make sure your existing data file does NOT get read into RAM again before you have a chance to manually repalce it with your updated data file, you ought to use WebSTAR's Refuse New Connections option while you're manually updating your data files on disk - then turn that option off AFTER you've finished replacing your old WebCat data files with the updated ones ... :)Sincerely, Ken Grome WebDNA Solutions http://www.hui.net/dna/webdna.html
Associated Messages, from the most recent to the oldest:
>I posted a related message about this last week. The single answer I got did >not quench my thirst for a better solution. > >I have enabled several store fronts with the WebCatalog acgi. I now want to >figure out an easy means of updating the various catalog.txt >database files.Well, do you have to do this one at a time or all at once?>Most clients will be maintaining these in locally operated database files and >exporting updates to me.Okay, then it looks like you're going to want to update these databases manually, one at a time.>I will then use Timbuktu to place them on the server.No problem ... but you're getting into a situation here that requires planning and an understanding of how WebCat works with RAM data vs. disk-based data.>However, it seems that >the only way I can do this is to effectively close and update EVERY database >file that WebCatalog has opened via the WebCatalog admin interface.That's right, before you replace and WebCat database file manually, you *MUST* make sure that that database data is purged from WebCat's RAM partition. If you fail to perform this step, you will soon find that your newly-updated data file get's overwritten by WebCat's RAM data - which is not what you really want to happen ... :)>Is there not a better way to close a single database and replace it with a >newer version without affecting over a dozen other database files?Yes, of course, that's what the
[closedatabase] tag is for. Using the
[closedatabase] tag you can close every database - individually. It's in the manual ...>Also, I seem to recall some discussion that the acgi version was not taking >manually entered updates. I remember one client trying to manually update the >ads.db and any new items he entered did not show up.This has nothing to do with the CGI vs. the plugin, it has to do with the user NOT understanding how to properly update his data files manually. That client simply failed to purge the RAM copy of his database file from WebCat's RAM partition before replacing the database on disk first.This is a common mistake for beginners when they choose to maintain their databases with other programs and update those databases manually - by replacing database files on the server - instead of making changes thru WebCatalog.>Is there something special that has to be done in >order to get WebCatalog to note that a change to the RAM-based file has been >made by a manually entered item?Yes, you have to close that database BEFORE you replace that data file on disk. Close it with the
[closedatabase] tag or the $flushdatabases command, but do it immediately before replacing the data file on disk.What's more, you have to be very fast when doing this, especially if your database is being accesses a lot ... because even though using the
[closedatabase] tag or the $flushdatabases command closes the database file and purges WebCat's RAM for that database, the same database will be loaded into RAM again the very next time someone requests info from that database.Therefore, if you really want to make sure your existing data file does NOT get read into RAM again before you have a chance to manually repalce it with your updated data file, you ought to use WebSTAR's Refuse New Connections option while you're manually updating your data files on disk - then turn that option off AFTER you've finished replacing your old WebCat data files with the updated ones ... :)Sincerely, Ken Grome WebDNA Solutions http://www.hui.net/dna/webdna.html
Kenneth Grome
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:
[shownext] and sort (1998)
WebCat Sites Hanging (!) (2003)
question: writing files textb in webmerch (1997)
Support ?? (1997)
Send massmail (2000)
Clickable maps and WebCatalog? (1996)
Sku numbers (1997)
wild question (1998)
Encrypt & SetHeader Length Problem (2000)
[SHOWIF AND/OR] (1997)
Emailer port change (1997)
Pithy questions on webcommerce & siteedit (1997)
Too many database headers? (2003)
Make sure I understand this??? (1997)
[WebDNA] Triggers (2016)
writefile, csv, tab and excel import behavior (2004)
WebStar Secure on other machine (1997)
Great product and great job ! (1997)
Limiting user access to .tmpl files (1997)
Multi-processor Mac info ... (1997)