Re: [ot] ShowIf & HideIf Question

This WebDNA talk-list message is from

1998

It keeps the original formatting. numero = 16231
interpreted = N
texte = >Webcatalog is limited>to 100 open databases. Sounds like a lot at first. Put a few stores up. Put>some more stores up. Use a bunch of lookups with each store. If I followed>Grant's advice, I'd tie up 7-10 additional databases PER store doing small>lookups.Hi Brian,I do not recall Grant ever suggesting the addition of 7-10 extra db's to each store for the purpose of doing lookups. If this is true, I'm kind of interested in knowing how and for what purpose each of these 7-10 additional db's are to be used. I've created plenty of online stores and I have never had to do anything like this before, so I think there are probably other ways of going about it that would be able to eliminate a lot of the extra databases on your site, thus expanding your capabilities.For example, if all those extra db's you're talking about are used for performing lookups, there are very easy ways to combine all those little db's into a single lookup database -- instead of using 7-10 separate db's.I also know of a way to do much the same thing without using a single additional database.If you need help in writing your WebDNA code in a way that minimizes the number of db's on your server so you can run more online stores without having your important db's closing in order to open lookup db's, let me know, maybe I can help you ... :)>Try explaining to your customer why your webserver is SOOO slow>when you are ONLY hosting 10 stores on the machine, but it decided to unload>their 20,000 product database from RAM because it wanted to load a lookup>table.I think you may need to revamp your WebDNA code, perhaps throughout your entire site including all your online stores, to get rid of all the extra db's you have in them that you probably don't need -- or else you might want to consider putting some more [closedatabase] tags into your code to close all those little db's after they are used, so they don't remain open and possibly cause larger, more important db's to close when you would rather keep the big ones open all the time.But no matter what you do, you will eventually run out of WebCat capacity anyways, especially if you continue to add more online stores to your single server. No matter how many db's WebCat can open, you will still run into the software's limits eventually.>And this problem isn't even dificult to fix. Why can't we use the>pipe character (above the backslash) to separate values in a [showif]>command?Does this have something to do with the 100 db limit? I don't understand how this relates to the problems you've expressed in the rest of this message. There are other ways of doing multiple showif/hideif tests without using lookups in special db's, I do this all the time using [math] contexts and variables.>Also, earlier today, I was talking about loading a fixed format file into a>database. It was suggested that this file just be loaded as a database, then>use a [getchars] command to strip out what i needed. Sounds great right? The>file in question is 84Meg daily updated. I need effectively 3 fields out of>it to replace values in a smaller product database.But you never said these things in your earlier posts. If you had, I would have offered different suggestions than my simple [getchars] suggestion. Like I said earlier, I deal with UNIX db's all the time -- and now that I have a better understanding of what you are trying to do, I have some questions ...What's the reason you need to maintain your WebCat data in an offline UNIX db? Wouldn't it be easier to maintain that data in WebCat on the server? Are you sure there's not a better method of doing what you seem to want to do? How many of the records in those 84 megs of data actually get changed every day? How do they get changed? Via TCP/IP, or directly by keyboarding the changes into the UNIX server, or via BBS, or email, or FTP, or some special UNIX script, or ???>But I want WebCatalog to do this, since it IS being>positioned as a single solution to web commerce.But WebCat was never positioned or promoted as a specialized solution for those who wish to continually import UNIX db files every day ... :)Have you tried using a desktop database program for this particular task? It might actually work better than trying to make WebCat do it, especially when any number of desktop database programs already have the built-in capabilities you're seeking -- since that's what they are designed for. Then you could let WebCat do what it was designed for, instead of trying to make it do things it was never meant to do.WebCat expects to use tab-delimited text files, so if you insist on feeding it data files in some other format while using work-arounds like [getchars], you're bound to run into limitations that are the direct result of your not using the standard tab-delimited format to begin with.>Back end data tie ins should be part of a $2500 program.I disagree. The price of a software program should not have any relation to the specific expectations of one or a handful of users. As long as the software does what it was promoted to do, that's all anyone has the right to expect.WebCat was never promoted to be a seamless link between UNIX data files and Web data serving, so I don't understand how you can claim that just because it's priced at $2500, it should perform the special tasks you might like it to perform.There are far more FileMaker users out there than UNIX users, and I'm sure they would love to have WebCat read FileMaker's native db format, too. But if WebCat is forced to deal with *any* db format other than its own native format, that will naturally slow WebCat down and create other problems as well.WebCat was designed for speed. From a common sense point of view, that means that one of the LAST things WebCat should have to do is to accommodate someone else's proprietary data format -- UNIX or FileMaker or SQL or Access or any other non-WebCat format.And dealing with a non-WebCat formatted data file is not even part of the core requirements of a high-speed web data server, it's an add-on feature that's already well provided for by any number of desktop database programs, most of which export tab-delimited text files exactly as WebCat needs them.I can write a Panorama procedure in about 15 minutes that will parse your UNIX data exactly the way WebCat should receive it. When Panorama is done with your UNIX file, it will export a WebCat-formatted db file that has only the remaining data in it that WebCat actually needs -- instead of the 84 megs that you're using now.>As for a common knowlede database for webcatalog, I'd be happy to program>it, and host it.This is great news for all of us. If you're serious about this, I think there may be several WebCatalog users who will honestly appreciate this. What do you have in mind, maybe there's something I can do to help ... :)Sincerely,Ken Gromeken@iav.com808-737-6499WebDNA Solutionshttp://webdna.net/ Associated Messages, from the most recent to the oldest:

Re: [ot] ShowIf & HideIf Question (Kenneth Grome 1998)
[ot] ShowIf & HideIf Question (Brian B. Burton 1998)

>Webcatalog is limited>to 100 open databases. Sounds like a lot at first. Put a few stores up. Put>some more stores up. Use a bunch of lookups with each store. If I followed>Grant's advice, I'd tie up 7-10 additional databases PER store doing small>lookups.Hi Brian,I do not recall Grant ever suggesting the addition of 7-10 extra db's to each store for the purpose of doing lookups. If this is true, I'm kind of interested in knowing how and for what purpose each of these 7-10 additional db's are to be used. I've created plenty of online stores and I have never had to do anything like this before, so I think there are probably other ways of going about it that would be able to eliminate a lot of the extra databases on your site, thus expanding your capabilities.For example, if all those extra db's you're talking about are used for performing lookups, there are very easy ways to combine all those little db's into a single lookup database -- instead of using 7-10 separate db's.I also know of a way to do much the same thing without using a single additional database.If you need help in writing your WebDNA code in a way that minimizes the number of db's on your server so you can run more online stores without having your important db's closing in order to open lookup db's, let me know, maybe I can help you ... :)>Try explaining to your customer why your webserver is SOOO slow>when you are ONLY hosting 10 stores on the machine, but it decided to unload>their 20,000 product database from RAM because it wanted to load a lookup>table.I think you may need to revamp your WebDNA code, perhaps throughout your entire site including all your online stores, to get rid of all the extra db's you have in them that you probably don't need -- or else you might want to consider putting some more [closedatabase] tags into your code to close all those little db's after they are used, so they don't remain open and possibly cause larger, more important db's to close when you would rather keep the big ones open all the time.But no matter what you do, you will eventually run out of WebCat capacity anyways, especially if you continue to add more online stores to your single server. No matter how many db's WebCat can open, you will still run into the software's limits eventually.>And this problem isn't even dificult to fix. Why can't we use the>pipe character (above the backslash) to separate values in a [showif]>command?Does this have something to do with the 100 db limit? I don't understand how this relates to the problems you've expressed in the rest of this message. There are other ways of doing multiple showif/hideif tests without using lookups in special db's, I do this all the time using [math] contexts and variables.>Also, earlier today, I was talking about loading a fixed format file into a>database. It was suggested that this file just be loaded as a database, then>use a [getchars] command to strip out what i needed. Sounds great right? The>file in question is 84Meg daily updated. I need effectively 3 fields out of>it to replace values in a smaller product database.But you never said these things in your earlier posts. If you had, I would have offered different suggestions than my simple [getchars] suggestion. Like I said earlier, I deal with UNIX db's all the time -- and now that I have a better understanding of what you are trying to do, I have some questions ...What's the reason you need to maintain your WebCat data in an offline UNIX db? Wouldn't it be easier to maintain that data in WebCat on the server? Are you sure there's not a better method of doing what you seem to want to do? How many of the records in those 84 megs of data actually get changed every day? How do they get changed? Via TCP/IP, or directly by keyboarding the changes into the UNIX server, or via BBS, or email, or FTP, or some special UNIX script, or ???>But I want WebCatalog to do this, since it IS being>positioned as a single solution to web commerce.But WebCat was never positioned or promoted as a specialized solution for those who wish to continually import UNIX db files every day ... :)Have you tried using a desktop database program for this particular task? It might actually work better than trying to make WebCat do it, especially when any number of desktop database programs already have the built-in capabilities you're seeking -- since that's what they are designed for. Then you could let WebCat do what it was designed for, instead of trying to make it do things it was never meant to do.WebCat expects to use tab-delimited text files, so if you insist on feeding it data files in some other format while using work-arounds like [getchars], you're bound to run into limitations that are the direct result of your not using the standard tab-delimited format to begin with.>Back end data tie ins should be part of a $2500 program.I disagree. The price of a software program should not have any relation to the specific expectations of one or a handful of users. As long as the software does what it was promoted to do, that's all anyone has the right to expect.WebCat was never promoted to be a seamless link between UNIX data files and Web data serving, so I don't understand how you can claim that just because it's priced at $2500, it should perform the special tasks you might like it to perform.There are far more FileMaker users out there than UNIX users, and I'm sure they would love to have WebCat read FileMaker's native db format, too. But if WebCat is forced to deal with *any* db format other than its own native format, that will naturally slow WebCat down and create other problems as well.WebCat was designed for speed. From a common sense point of view, that means that one of the LAST things WebCat should have to do is to accommodate someone else's proprietary data format -- UNIX or FileMaker or SQL or Access or any other non-WebCat format.And dealing with a non-WebCat formatted data file is not even part of the core requirements of a high-speed web data server, it's an add-on feature that's already well provided for by any number of desktop database programs, most of which export tab-delimited text files exactly as WebCat needs them.I can write a Panorama procedure in about 15 minutes that will parse your UNIX data exactly the way WebCat should receive it. When Panorama is done with your UNIX file, it will export a WebCat-formatted db file that has only the remaining data in it that WebCat actually needs -- instead of the 84 megs that you're using now.>As for a common knowlede database for webcatalog, I'd be happy to program>it, and host it.This is great news for all of us. If you're serious about this, I think there may be several WebCatalog users who will honestly appreciate this. What do you have in mind, maybe there's something I can do to help ... :)Sincerely,Ken Gromeken@iav.com808-737-6499WebDNA Solutionshttp://webdna.net/ Kenneth Grome

DOWNLOAD WEBDNA NOW!

Re: [ot] ShowIf & HideIf Question

1998

Top Articles:

Related Readings: