Re: [WebDNA] table comma field delimiter bug?
This WebDNA talk-list message is from 2012
It keeps the original formatting.
numero = 108095
interpreted = N
texte = Kenneth Grome wrote: > If I enter the data into the table as shown here, the commas are interpreted by WebDNA as field separators > when I search the table. > > Naturally I can URL the field values by wrapping the [interpret][[fieldname]][/interpret] part in a URL context, and > this actually defeats WebDNA's "table comma bug" because it never sees the commas, it only see the URLed > comma values ... but then the data is displayed as URLed values on the web page, thus the reason why I have to > UNURL them to get them to display properly. > > So like I said earlier, it's a bug ... or it's a mistake in the docs, whichever you want to call it ... but WebDNA is > clearly seeing the commas as field delimiters even though the data is entered correctly as tab-delimited text. In > my opinion it should not interpret commas as field separators in this situation, because the proper way to input > data like this is ONLY to enter the data as tab-delimited text. > > Yes I know, I can probably input the data via a series of appends and not experience this problem. But the point > is that the docs say I am entering the data correctly. So if WebDNA's internal code will not be changed in an > effort to get rid of this "bug", then the docs should be changed so that they only allow data to be entered into a > table via via append ... > > Or at least mention the fact that if you use the data input method shown in the docs, you cannot enter any > commas unless you also URL the comma-filled fields going in, and then unurl them coming out. > > Sincerely, > Kenneth Grome > > [table name=theData&fields=[getchars start=2&from=end][listfields db=source.db][fieldname],[/listfields] > [/getchars]] > [search db=source.db&neskudatarq=[blank]&rank=off][founditems][getchars start=2&from=end][listfields > db=source.db][interpret][[fieldname]][/interpret] [/listfields][/getchars] > [/founditems][/search][/table] > > > [search table=theData&neskudatarq=[blank]&rank=off] > [founditems] > > [/founditems] > [/search] Merge format has been around for a long time Ken, but yes, perhaps the table page should make a mention to the merge format: http://docs.webdna.us/pages.html?context=DatabaseFormat.html Donovan -- Donovan Brooke Euca Design Center www.euca.us
Associated Messages, from the most recent to the oldest:
Kenneth Grome wrote: > If I enter the data into the table as shown here, the commas are interpreted by WebDNA as field separators > when I search the table. > > Naturally I can URL the field values by wrapping the
[interpret][[fieldname]][/interpret] part in a URL context, and > this actually defeats WebDNA's "table comma bug" because it never sees the commas, it only see the URLed > comma values ... but then the data is displayed as URLed values on the web page, thus the reason why I have to > UNURL them to get them to display properly. > > So like I said earlier, it's a bug ... or it's a mistake in the docs, whichever you want to call it ... but WebDNA is > clearly seeing the commas as field delimiters even though the data is entered correctly as tab-delimited text. In > my opinion it should not interpret commas as field separators in this situation, because the proper way to input > data like this is ONLY to enter the data as tab-delimited text. > > Yes I know, I can probably input the data via a series of appends and not experience this problem. But the point > is that the docs say I am entering the data correctly. So if WebDNA's internal code will not be changed in an > effort to get rid of this "bug", then the docs should be changed so that they only allow data to be entered into a > table via via append ... > > Or at least mention the fact that if you use the data input method shown in the docs, you cannot enter any > commas unless you also URL the comma-filled fields going in, and then unurl them coming out. > > Sincerely, > Kenneth Grome > > [table name=theData&fields=[getchars start=2&from=end][listfields db=source.db][fieldname],[/listfields] > [/getchars]] > [search db=source.db&neskudatarq=[blank]&rank=off]
[founditems][getchars start=2&from=end][listfields > db=source.db]
[interpret][[fieldname]][/interpret] [/listfields][/getchars] > [/founditems][/search][/table] > > > [search table=theData&neskudatarq=[blank]&rank=off] >
[founditems] > > [/founditems] > [/search] Merge format has been around for a long time Ken, but yes, perhaps the table page should make a mention to the merge format: http://docs.webdna.us/pages.html?context=DatabaseFormat.html Donovan -- Donovan Brooke Euca Design Center www.euca.us
Donovan Brooke
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:
WebCat2b13MacPlugIn - More limits on [include] (1997)
WCf2 and nested tags (1997)
Sku numbers (1997)
OT: zipcodes (2002)
WebCatalog NT beta 18 now available (1997)
[ModDate] & [ModTime] ? (1997)
%@#*& back button!!! (1999)
WebDNA 5.x & iTools 7 & Apache 2 (2003)
really annoying feature (2001)
Template Encryption (1998)
Searching for (field1 OR field2) AND field3 (2000)
[TaxableTotal] - not working with AOL and IE (1997)
RAM variables (1997)
[protect] error page (1997)
WebCatalog and WebMerchant reviewed by InfoWorld (1997)
Change Subtotal (2000)
did I miss anything (1997)
2.0 Info (1997)
WebCat2b15MacPlugIn - [authenticate] not [protect] (1997)
Toronto area? (1999)