Re: FEA REQ: One .hdr, multiple .db's

This WebDNA talk-list message is from

2003

It keeps the original formatting. numero = 52390
interpreted = N
texte = > >Please tell me what I've missed that will prevent this 10 minute>>solution from doing exactly what you want to do with any number of>>db's that need the same new fields added to them from time to> >time ...>>I have an intranet system that I am constructing right now. Each >project gets its own set of dbs for a schedule, tasks, resources, >etc. This way, if a project gets canned, archived, changed, etc. I >don't have to muck with one database, I can just moved the matching >dbs' directory.If it were my project I would write an admin template that copies all the records for a specific project to one set of archive db's, then it would delete those same records from the main db's. And if the project gets canned instead of archived, I would just delete those records from the main db's. Then I would have to manage only TWO sets of db's instead of an ever-increasing number of them.It sure seems to me that you're making more work for yourself than you have to -- and creating a demand for an unnecessary feature in the process -- because of the way you have chosen to construct your system.Why don't you re-think your multiple-db approach? Over the years I have learned that it is almost always best to have as few db's as necessary in my webdna solutions. This means never generating another new set of db's to do what ONE set of db's can do. It may mean adding a field or two to a single set of db's and then managing that one set with properly developed admin templates, but that's a whole lot easier and more efficient in the long run, for most solutions anyways.>While this could be done with one set of dbs for the whole system... >30 projects a month gets kind of cumbersome when you're dealing with >one database.Why does it "get kind of cumbersome" with only one set of db's? To me it's a lot more cumbersome to have to deal with innumerable sets of db's instead of just one set. I never use a separate set of db's when a single set of databases can easily do the same thing. Instead I figure out ways to keep the number of db's down to a reasonable minimum, specifically so I do not have to manage any more db's than necessary.>I would need to change over 100 database headers at a time. A >webDNA script is fine and dandy, but include files were built so >that I could update one file and have it change across the site... >Why can't I do the same with a database header for multiple >databases?Maybe because most people would use a single db and therefore they would not have the problem of changing a hundred .hdr files.>I realize it's usefulness would be limited to multiple dbs, but >aren't there other "specialty" commands in webDNA? [exclusivelock] >probably doesn't get used routinely by most programmers, but it's >still there and a very useful context when it is needed.Exclusivelock is something we cannot easily do without when we need it. But your multiple .hdr issue can easily be dealt with (as I illustrated earlier) in a few simple lines of webdna code. Or better yet, do not create all those db's in the first place ... :)Believe me, I've tried a couple of times to do it your way, and each time I have come to the conclusion that the fewer db's I have to deal with the better. So I always seem to go back to using one main set of db's (and possibly another set for archived records) -- and that's it.-- Sincerely,Kenneth Grome-------------------------------------------------------------Outsource your WebDNA programming for $18 an hour or less!--------------------------------------------------------------------------------------------------------------------------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:

Re: FEA REQ: One .hdr, multiple .db's ( "WebDna @" 2003)
Re: FEA REQ: One .hdr, multiple .db's ( Terry Wilson 2003)
Re: FEA REQ: One .hdr, multiple .db's ( Kenneth Grome 2003)
Re: FEA REQ: One .hdr, multiple .db's ( Matthew Bohne 2003)
Re: FEA REQ: One .hdr, multiple .db's ( "Gary Krockover" 2003)
Re: FEA REQ: One .hdr, multiple .db's ( Kenneth Grome 2003)
Re: FEA REQ: One .hdr, multiple .db's ( "Nitai @ ComputerOil" 2003)
Re: FEA REQ: One .hdr, multiple .db's ( Kenneth Grome 2003)
Re: FEA REQ: One .hdr, multiple .db's ( "Nitai @ ComputerOil" 2003)
Re: FEA REQ: One .hdr, multiple .db's ( Matthew Bohne 2003)
Re: FEA REQ: One .hdr, multiple .db's ( Terry Wilson 2003)
Re: FEA REQ: One .hdr, multiple .db's ( "Nitai @ ComputerOil" 2003)
Re: FEA REQ: One .hdr, multiple .db's ( Kenneth Grome 2003)
Re: FEA REQ: One .hdr, multiple .db's ( "Scott Anderson" 2003)
Re: FEA REQ: One .hdr, multiple .db's ( "Scott Anderson" 2003)
Re: FEA REQ: One .hdr, multiple .db's ( Stuart Tremain 2003)
Re: FEA REQ: One .hdr, multiple .db's ( Donovan 2003)
Re: FEA REQ: One .hdr, multiple .db's ( Scott Anderson 2003)
Re: FEA REQ: One .hdr, multiple .db's ( Matthew Bohne 2003)
Re: FEA REQ: One .hdr, multiple .db's ( Brian Fries 2003)
Re: FEA REQ: One .hdr, multiple .db's ( John Hill 2003)
Re: FEA REQ: One .hdr, multiple .db's ( John Peacock 2003)
Re: FEA REQ: One .hdr, multiple .db's ( "Scott Anderson" 2003)
Re: FEA REQ: One .hdr, multiple .db's ( "Nitai @ ComputerOil" 2003)
Re: FEA REQ: One .hdr, multiple .db's ( Donovan 2003)
Re: FEA REQ: One .hdr, multiple .db's ( "Nitai @ ComputerOil" 2003)
Re: FEA REQ: One .hdr, multiple .db's ( "WebDna @" 2003)
Re: FEA REQ: One .hdr, multiple .db's ( "Nitai @ ComputerOil" 2003)
FEA REQ: One .hdr, multiple .db's ( Matthew Bohne 2003)

> >Please tell me what I've missed that will prevent this 10 minute>>solution from doing exactly what you want to do with any number of>>db's that need the same new fields added to them from time to> >time ...>>I have an intranet system that I am constructing right now. Each >project gets its own set of dbs for a schedule, tasks, resources, >etc. This way, if a project gets canned, archived, changed, etc. I >don't have to muck with one database, I can just moved the matching >dbs' directory.If it were my project I would write an admin template that copies all the records for a specific project to one set of archive db's, then it would delete those same records from the main db's. And if the project gets canned instead of archived, I would just delete those records from the main db's. Then I would have to manage only TWO sets of db's instead of an ever-increasing number of them.It sure seems to me that you're making more work for yourself than you have to -- and creating a demand for an unnecessary feature in the process -- because of the way you have chosen to construct your system.Why don't you re-think your multiple-db approach? Over the years I have learned that it is almost always best to have as few db's as necessary in my webdna solutions. This means never generating another new set of db's to do what ONE set of db's can do. It may mean adding a field or two to a single set of db's and then managing that one set with properly developed admin templates, but that's a whole lot easier and more efficient in the long run, for most solutions anyways.>While this could be done with one set of dbs for the whole system... >30 projects a month gets kind of cumbersome when you're dealing with >one database.Why does it "get kind of cumbersome" with only one set of db's? To me it's a lot more cumbersome to have to deal with innumerable sets of db's instead of just one set. I never use a separate set of db's when a single set of databases can easily do the same thing. Instead I figure out ways to keep the number of db's down to a reasonable minimum, specifically so I do not have to manage any more db's than necessary.>I would need to change over 100 database headers at a time. A >webDNA script is fine and dandy, but include files were built so >that I could update one file and have it change across the site... >Why can't I do the same with a database header for multiple >databases?Maybe because most people would use a single db and therefore they would not have the problem of changing a hundred .hdr files.>I realize it's usefulness would be limited to multiple dbs, but >aren't there other "specialty" commands in webDNA? [exclusivelock] >probably doesn't get used routinely by most programmers, but it's >still there and a very useful context when it is needed.Exclusivelock is something we cannot easily do without when we need it. But your multiple .hdr issue can easily be dealt with (as I illustrated earlier) in a few simple lines of webdna code. Or better yet, do not create all those db's in the first place ... :)Believe me, I've tried a couple of times to do it your way, and each time I have come to the conclusion that the fewer db's I have to deal with the better. So I always seem to go back to using one main set of db's (and possibly another set for archived records) -- and that's it.-- Sincerely,Kenneth Grome-------------------------------------------------------------Outsource your WebDNA programming for $18 an hour or less!--------------------------------------------------------------------------------------------------------------------------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/ Kenneth Grome

DOWNLOAD WEBDNA NOW!

Re: FEA REQ: One .hdr, multiple .db's

2003

Top Articles:

Related Readings: