Re: Fwd: [WebDNA] Fails to recognize comma-separated db
This WebDNA talk-list message is from 2010
It keeps the original formatting.
numero = 105393
interpreted = N
texte = I don't know why webdna was ever coded to require two different formats for field names and field values in csv files, but it seems like a foolish way to do it -- because it is NOT consistent with tab-delimited format which uses tabs to separate both field names *and* field values. What I got from my online bank was a file that had both the field values and the field names separated by commas. It failed in webdna. Then I modified the file by surrounding all the commas with quotes to make it a "quote-comma-quote" separated file. This also failed in webdna. According to your example we must use ONLY commas to separate field names, then we have to use commas surrounded by quotes to separate field values. In other words, we have to use two different formats if we expect webdna to work properly with csv files. Why are we required to use two different formats in the same file in order for webdna to use that file successfully as one of its databases??? Personally I think it would "make sense" to re-code webdna so that it can handle csv files that use ONLY commas as separators for both field names and field values, and so that it cal also handle csv files that use commas surrounded by quotes as separators for both field names and field values -- since these are the typical ways csv files are formatted in the industry (in my experience anyways). By the way, I'm assuming that the different format requirement for field names vs. field values is the cause of my problem. Is this the actual cause ... or is something else going on here? Sincerely, Kenneth Grome > Hello everybody, and particularely Ken, Matt and Stuart. We would not like to leave a bug if there is a problem with the Merge format. Please, could you confirm there is indeed a problem of databases not read using this format? in this case, woud you be so kind to post the field names format and one or two lines of your databases. > > As explained in WebDNA website, the proper format is > > ---------------------------------------------------------------- > name,address,city,state,zip > "Grant","1180 Central Ave","San Marcos","CA","92079" > "PCS","11770 Bernardo Plaza Court","San Diego","CA","92128" > ---------------------------------------------------------------- > > and it works, at least for me. Here a small test: just upload this to any WebDNA served website and open "states2.dna" file with your browser. > >
Associated Messages, from the most recent to the oldest:
I don't know why webdna was ever coded to require two different formats for field names and field values in csv files, but it seems like a foolish way to do it -- because it is NOT consistent with tab-delimited format which uses tabs to separate both field names *and* field values. What I got from my online bank was a file that had both the field values and the field names separated by commas. It failed in webdna. Then I modified the file by surrounding all the commas with quotes to make it a "quote-comma-quote" separated file. This also failed in webdna. According to your example we must use ONLY commas to separate field names, then we have to use commas surrounded by quotes to separate field values. In other words, we have to use two different formats if we expect webdna to work properly with csv files. Why are we required to use two different formats in the same file in order for webdna to use that file successfully as one of its databases??? Personally I think it would "make sense" to re-code webdna so that it can handle csv files that use ONLY commas as separators for both field names and field values, and so that it cal also handle csv files that use commas surrounded by quotes as separators for both field names and field values -- since these are the typical ways csv files are formatted in the industry (in my experience anyways). By the way, I'm assuming that the different format requirement for field names vs. field values is the cause of my problem. Is this the actual cause ... or is something else going on here? Sincerely, Kenneth Grome > Hello everybody, and particularely Ken, Matt and Stuart. We would not like to leave a bug if there is a problem with the Merge format. Please, could you confirm there is indeed a problem of databases not read using this format? in this case, woud you be so kind to post the field names format and one or two lines of your databases. > > As explained in WebDNA website, the proper format is > > ---------------------------------------------------------------- > name,address,city,state,zip > "Grant","1180 Central Ave","San Marcos","CA","92079" > "PCS","11770 Bernardo Plaza Court","San Diego","CA","92128" > ---------------------------------------------------------------- > > and it works, at least for me. Here a small test: just upload this to any WebDNA served website and open "states2.dna" file with your browser. > >
Kenneth Grome
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:
upgrade problem with users.db (1998)
E-Mail Formatting (2000)
No luck with taxes (1997)
Target wit redirect (1998)
Country & Ship-to address & other fields ? (1997)
Emailer again & again (1997)
-REPOST- WebCat 3 & Aliases (2000)
Separate SSL Server (1997)
access denied problem (1997)
Using WebCat for product info requests (1997)
RE: PDF (1999)
Sorting Numbers (1997)
Using Plug-In while running 1.6.1 (1997)
possible, WebCat2.0 and checkboxes-restated (1997)
Return records from another (1997)
Download URL & access on the fly ? (1997)
Reference data: ip-to-country (2004)
GuestBook example (1997)
Dynamic Pop up menu? (1997)
service stop and restart (1997)