Re: [WebDNA] Re: table comma field delimiter bug?

This WebDNA talk-list message is from

2012


It keeps the original formatting.
numero = 108102
interpreted = N
texte = --20cf303ea7a836465104b6664260 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would do the first. Tables are created for a page, usually as a subset or mashup of databases. In other words, likely not enough usage to merit much attention. I think people may use that format to export from other database programs and the functionality is working already so I would not break that for databases. Bill On Fri, Jan 13, 2012 at 4:48 AM, wrote: > Hi everybody! interesting thread. I just did some tests myself and also > found that commas were interpreted as field delimiters in tables. I do no= t > think it is a bug, but it is an inconsistency. > > http://www.webdna.us/page.dna?numero=3D214 > > Here an ex: > > "PCS","11770, Bernardo Plaza Court","San Diego","CA","92128" > > At this time the comma in the street field is interpreted as delimiter. I= t > clearly should not. > > Since my plans are to =91normalize=92 inconsistencies in current WebDNA > language in the next versions, i have a listing of all notes and requests > found on this talk-list during the last 3 years. > > In this case, and in order to keep [table] and database format on par > - should we deprecate the comma field delimiters in tables? > - should we deprecate the comma field delimiters in databases and tables? > - should we enforce the comma field delimiters in databases and tables by > using "," (a comma surrounded by two quotation marks)? in this case, the > quotation mark would become an essential part of the database/table forma= t, > and the lack of a single quotation mark would "break" the database format= . > > > > - chris > > > > > On Jan 13, 2012, at 5:34, Tom Duke wrote: > > > Ken, > > > > Hi - I have experienced the same issues as yourself. The discussion a= t > the time clarified that commas were interpreted as field delimiters withi= n > tables and could not be used. > > > > The simplest way to deal with this is to set up your table but then add > data using [append] and [url]'ing the values. > > > > - Tom > > --------------------------------------------------------- This message > is sent to you because you are subscribed to the mailing list . To > unsubscribe, E-mail to: archives: > http://mail.webdna.us/list/talk@webdna.us Bug Reporting: support@webdna.u= s > > --------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us > Bug Reporting: support@webdna.us > --20cf303ea7a836465104b6664260 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would do the first. =A0Tables are created for a page, usually as a subset= or mashup of databases. =A0In other words, likely not enough usage to meri= t much attention. =A0

I think people may use that format= to export from other database programs and the functionality is working al= ready so I would not break that for databases. =A0

Bill

On Fri, Jan 13, = 2012 at 4:48 AM, <christophe.billiottet@webdna.us> wrote:
Hi everybody! interesting thread. I just did some tests myself and also fou= nd that commas were interpreted as field delimiters in tables. I do not thi= nk it is a bug, but it is an inconsistency.

ht= tp://www.webdna.us/page.dna?numero=3D214

Here an ex:

"PCS","11770, Bernardo Plaza Court","San Diego&quo= t;,"CA","92128"

At this time the comma in the street field is interpreted as delimiter. It = clearly should not.

Since my plans are to =91normalize=92 inconsistencies in current WebDNA lan= guage in the next versions, i have a listing of all notes and requests foun= d on this talk-list during the last 3 years.

In this case, and in order to keep [table] and =A0database format on par - should we deprecate the comma field delimiters in tables?
- should we deprecate the comma field delimiters in databases and tables? - should we enforce the comma field delimiters in databases and tables by u= sing "," (a comma surrounded by two quotation marks)? in this cas= e, the quotation mark would become an essential part of the database/table = format, and the lack of a single quotation mark would "break" the= database format.



- chris




On Jan 13, 2012, at 5:34, Tom Duke wrote:

> Ken,
>
> Hi - I have experienced the same issues as yourself. =A0 The discussio= n at the time clarified that commas were interpreted as field delimiters wi= thin tables and could not be used.
>
> The simplest way to deal with this is to set up your table but then ad= d data using [append] and [url]'ing the values.
>
> - Tom
> --------------------------------------------------------- This message= is sent to you because you are subscribed to the mailing list . To unsubsc= ribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.us Bug R= eporting: support@webdna.us

---------------------------------------------------------
This message is sent to you because you are subscribed to
the mailing list <talk@web= dna.us>.
To unsubscribe, E-mail to: <talk= -leave@webdna.us>

--20cf303ea7a836465104b6664260-- Associated Messages, from the most recent to the oldest:

    
  1. Re: [WebDNA] table comma field delimiter bug? (Donovan Brooke 2012)
  2. Re: [WebDNA] table comma field delimiter bug? (Kenneth Grome 2012)
  3. Re: [WebDNA] table comma field delimiter bug? (Govinda 2012)
  4. Re: [WebDNA] table comma field delimiter bug? (Donovan Brooke 2012)
  5. Re: [WebDNA] table comma field delimiter bug? (Kenneth Grome 2012)
  6. Re: [WebDNA] table comma field delimiter bug? (Donovan Brooke 2012)
  7. Re: [WebDNA] table comma field delimiter bug? (Donovan Brooke 2012)
  8. [WebDNA] table comma field delimiter bug? (Kenneth Grome 2012)
--20cf303ea7a836465104b6664260 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would do the first. Tables are created for a page, usually as a subset or mashup of databases. In other words, likely not enough usage to merit much attention. I think people may use that format to export from other database programs and the functionality is working already so I would not break that for databases. Bill On Fri, Jan 13, 2012 at 4:48 AM, wrote: > Hi everybody! interesting thread. I just did some tests myself and also > found that commas were interpreted as field delimiters in tables. I do no= t > think it is a bug, but it is an inconsistency. > > http://www.webdna.us/page.dna?numero=3D214 > > Here an ex: > > "PCS","11770, Bernardo Plaza Court","San Diego","CA","92128" > > At this time the comma in the street field is interpreted as delimiter. I= t > clearly should not. > > Since my plans are to =91normalize=92 inconsistencies in current WebDNA > language in the next versions, i have a listing of all notes and requests > found on this talk-list during the last 3 years. > > In this case, and in order to keep [table] and Database format on par > - should we deprecate the comma field delimiters in tables? > - should we deprecate the comma field delimiters in databases and tables? > - should we enforce the comma field delimiters in databases and tables by > using "," (a comma surrounded by two quotation marks)? in this case, the > quotation mark would become an essential part of the database/table forma= t, > and the lack of a single quotation mark would "break" the Database format= . > > > > - chris > > > > > On Jan 13, 2012, at 5:34, Tom Duke wrote: > > > Ken, > > > > Hi - I have experienced the same issues as yourself. The discussion a= t > the time clarified that commas were interpreted as field delimiters withi= n > tables and could not be used. > > > > The simplest way to deal with this is to set up your table but then add > data using [append] and [url]'ing the values. > > > > - Tom > > --------------------------------------------------------- This message > is sent to you because you are subscribed to the mailing list . To > unsubscribe, E-mail to: archives: > http://mail.webdna.us/list/talk@webdna.us Bug Reporting: support@webdna.u= s > > --------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us > Bug Reporting: support@webdna.us > --20cf303ea7a836465104b6664260 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would do the first. =A0Tables are created for a page, usually as a subset= or mashup of databases. =A0In other words, likely not enough usage to meri= t much attention. =A0

I think people may use that format= to export from other database programs and the functionality is working al= ready so I would not break that for databases. =A0

Bill

On Fri, Jan 13, = 2012 at 4:48 AM, <christophe.billiottet@webdna.us> wrote:
Hi everybody! interesting thread. I just did some tests myself and also fou= nd that commas were interpreted as field delimiters in tables. I do not thi= nk it is a bug, but it is an inconsistency.

ht= tp://www.webdna.us/page.dna?numero=3D214

Here an ex:

"PCS","11770, Bernardo Plaza Court","San Diego&quo= t;,"CA","92128"

At this time the comma in the street field is interpreted as delimiter. It = clearly should not.

Since my plans are to =91normalize=92 inconsistencies in current WebDNA lan= guage in the next versions, i have a listing of all notes and requests foun= d on this talk-list during the last 3 years.

In this case, and in order to keep [table] and =A0Database format on par - should we deprecate the comma field delimiters in tables?
- should we deprecate the comma field delimiters in databases and tables? - should we enforce the comma field delimiters in databases and tables by u= sing "," (a comma surrounded by two quotation marks)? in this cas= e, the quotation mark would become an essential part of the database/table = format, and the lack of a single quotation mark would "break" the= Database format.



- chris




On Jan 13, 2012, at 5:34, Tom Duke wrote:

> Ken,
>
> Hi - I have experienced the same issues as yourself. =A0 The discussio= n at the time clarified that commas were interpreted as field delimiters wi= thin tables and could not be used.
>
> The simplest way to deal with this is to set up your table but then ad= d data using [append] and [url]'ing the values.
>
> - Tom
> --------------------------------------------------------- This message= is sent to you because you are subscribed to the mailing list . To unsubsc= ribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.us Bug R= eporting: support@webdna.us

---------------------------------------------------------
This message is sent to you because you are subscribed to
the mailing list <talk@web= dna.us>.
To unsubscribe, E-mail to: <talk= -leave@webdna.us>

--20cf303ea7a836465104b6664260-- William DeVaul

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:

Newbie Tax Question (1997) WebCat2b14MacPlugIn - [include] doesn't hide the search string (1997) Problems with [Search] param - Mac Plugin b15 (1997) Items XX to XX shown (1997) [OT] USA States (2003) [WebDNA] Discussion Forum (2009) WebCat2 - Getting to the browser's username/password data (1997) Show if time tags (1997) Restricting templates from causing havoc (2000) Document Contains No Data! (1997) Location of Browser Info.txt file (1997) Webcat causing crashes left and right! (1997) HELP - NONE STOP DIGESTS. Digest for 4/24/97) (1997) [WebDNA] Clean URLS job - will pay (2010) SiteGuard Admin Feature ? (1997) RE: Signal Raised (1997) Universal db access template ... (2002) Search Engine questions ... (2002) Bug or syntax error on my part? (1997) [WebDNA] WebDNA and MAMP/Apache (Mac) (2018)