Re: tabs as delimiters NOT

This WebDNA talk-list message is from

2004

It keeps the original formatting. numero = 59730
interpreted = N
texte = Yes, the pipe is my delimiter of choice. I love the pipe; easy to see, graphically represents what it's doing, not a normal character; I've been using it for a long time, and still do, even with my workaround for this situation. If you refer back to the beginning of this thread, the problem arose when my pipe-delimited values collapsed if they were empty values. In a 5 part address scheme, if the first value (the place name, like a restaurant name) is empty (as if it were just at someone's house), then that value is ignored, and everything else moves up a notch, so the state is where the city belongs, the zip is where the state belongs, and the zip is something like [add5]. So I went to the online docs, and found that you can use tabs=T to cause empty values to be recognized as values, and not collapsed. Problem is, that you have to use TABS as delimiters. This is per SMSI documentation. So I tried that, and it does work if your values are pulled in via an included text file, but how on earth do you store a tab in a WebCat DB? You can't, and if you use the ascii value, it simply doesn't work. Grep doesn't work, convert chars doesn't work (comes out of a DB) using a table instead of a db doesn't work... it just doesn't work from a DB stored wordlist. So that's where my brief experiment with tabs as delimiters came from. Like I say, I solved it by prepending qz_ to my pipe-delimited values so there'd be a value in the first place, then grepping qz_ out upon displaying the values. (By the way, I also discovered that if you use getchars, and say you use start=4, then if your value only has 3 or less characters, getchars will defy your instructions and give you the last char, rather than giving you a blank. "Oh well..." on that idea.)The topic of collapsing values only came up once or twice in the list archives; that really surprised me.Terry>Terry Wilson wrote:>> No, not a dumb question. Nowadays, nearly all of my sites employ a>> single database with the first record (sometimes two) being a Settings>> record holding sitewide settings that are put into text variables at the>> top of every page.>And this is a perfectly reasonable solution. However, trying to use>tabs as a delimiter isn't; that is what WebDNA uses as it's own>delimiter so you don't have that available for subfields. Have you>considered the pipe character "|" which is not normally present in any>reasonable set of characters used for data input purposes? Your problem>is not your design, but your implementation, AFAICT.>HTH>John-------------------------------------------------------------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: tabs as delimiters NOT ( Rob Marquardt 2004)
Re: tabs as delimiters NOT ( Terry Wilson 2004)

Yes, the pipe is my delimiter of choice. I love the pipe; easy to see, graphically represents what it's doing, not a normal character; I've been using it for a long time, and still do, even with my workaround for this situation. If you refer back to the beginning of this thread, the problem arose when my pipe-delimited values collapsed if they were empty values. In a 5 part address scheme, if the first value (the place name, like a restaurant name) is empty (as if it were just at someone's house), then that value is ignored, and everything else moves up a notch, so the state is where the city belongs, the zip is where the state belongs, and the zip is something like [add5]. So I went to the online docs, and found that you can use tabs=T to cause empty values to be recognized as values, and not collapsed. Problem is, that you have to use TABS as delimiters. This is per SMSI documentation. So I tried that, and it does work if your values are pulled in via an included text file, but how on earth do you store a tab in a WebCat DB? You can't, and if you use the ascii value, it simply doesn't work. Grep doesn't work, convert chars doesn't work (comes out of a DB) using a table instead of a db doesn't work... it just doesn't work from a DB stored wordlist. So that's where my brief experiment with tabs as delimiters came from. Like I say, I solved it by prepending qz_ to my pipe-delimited values so there'd be a value in the first place, then grepping qz_ out upon displaying the values. (By the way, I also discovered that if you use getchars, and say you use start=4, then if your value only has 3 or less characters, getchars will defy your instructions and give you the last char, rather than giving you a blank. "Oh well..." on that idea.)The topic of collapsing values only came up once or twice in the list archives; that really surprised me.Terry>Terry Wilson wrote:>> No, not a dumb question. Nowadays, nearly all of my sites employ a>> single database with the first record (sometimes two) being a Settings>> record holding sitewide settings that are put into text variables at the>> top of every page.>And this is a perfectly reasonable solution. However, trying to use>tabs as a delimiter isn't; that is what WebDNA uses as it's own>delimiter so you don't have that available for subfields. Have you>considered the pipe character "|" which is not normally present in any>reasonable set of characters used for data input purposes? Your problem>is not your design, but your implementation, AFAICT.>HTH>John-------------------------------------------------------------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/ Terry Wilson

DOWNLOAD WEBDNA NOW!

Re: tabs as delimiters NOT

2004

Top Articles:

Related Readings: