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:
Possible Macv2.1b2 Merge Bug (1997)
unsubscribe (1999)
test (2000)
errormessages.db (1997)
WebTen and WebCat (1997)
File Upload (1997)
shipCost -vs- shippingtotal ? (2000)
too many nested tags ... (1997)
WebCatalog Eating 200% of the CPU (2002)
Snake Bites (1997)
Re[2]: Re[2]: WebCatalog on Linux (2000)
Web Catalog 2 demo (1997)
SSL Certs (2003)
Credit card types (1997)
For those of you not on the WebCatalog Beta... (1997)
popups, netscape vs explorer (1997)
Re:2nd WebCatalog2 Feature Request (1996)
Links to show shopping cart. (1998)
A sendmail warning (2005)
Mozilla/4. and Browser Info.txt (1997)