Re: Special characters in field names

This WebDNA talk-list message is from

1998


It keeps the original formatting.
numero = 21733
interpreted = N
texte = >What about ampersands in field data? I find alot of ampersands in the >text I get from customers and they seem to do strange things to the >searches when they exist in the database. If I convert all to & I >still have an ampersand, it just isn't standing by itself. What's the >PCS recommended proceedure regarding ampersands in database fields?The correct, safe way to do any operation where you're not in complete control of the data (as in when visitors enter their own data) is to 'URL-ize' the data before it's put into the database:[Append db=xx]field1=[URL][form_field1_value][/URL]&field2=[URL][form_field2_value][/URL ][/Append]What happens here is any & inside [form_field1_value] get converted to %26, which is the URL-equivalent of &. WebCatalog see this and converts it back to & automatically at the point it actually gets written to the database. An '=' will also cause trouble unless you use this technique.So to make a fine point: literal ampersands are fine inside a database field (for instance, if you export a database from another source that happens to already contain & in the data). Having the & there is not going to hurt the database, nor is it going to mess up the *retrieval* of those fields from the database.The real issue we're resolving here is those times when a *browser* is involved in the process, such as those times when you are building an HREF, because the & has a special meaning inside an HREF, just like ?, /, =, and #. Since WebCatalog's embedded WebDNA contexts also use this syntax, you must also 'protect' your text with [URL] when using embedded contexts. Basically a computer cannot tell the difference between an & *inside* your field, vs. one that delimits the beginning of a new name=value pair.Technical Support | ==== eCommerce and Beyond ==== Pacific Coast Software | WebCatalog, WebMerchant, 11770 Bernardo Plaza Court | SiteEdit Pro, PhotoMaster, San Diego, CA 92128 | Typhoon 619/675-1106 Fax: 619/675-0372 | http://www.smithmicro.com/ Associated Messages, from the most recent to the oldest:

    
  1. Re: Special characters in field names (PCS Technical Support 1998)
  2. Re: Special characters in field names (PCS Technical Support 1998)
  3. Re: Special characters in field names (PCS Technical Support 1998)
  4. Re: Special characters in field names (Sandra L. Pitner 1998)
  5. Re: Special characters in field names (Mike Davis 1998)
  6. Re: Special characters in field names (PCS Technical Support 1998)
  7. Special characters in field names (Kenneth Grome 1998)
>What about ampersands in field data? I find alot of ampersands in the >text I get from customers and they seem to do strange things to the >searches when they exist in the database. If I convert all to & I >still have an ampersand, it just isn't standing by itself. What's the >PCS recommended proceedure regarding ampersands in database fields?The correct, safe way to do any operation where you're not in complete control of the data (as in when visitors enter their own data) is to 'URL-ize' the data before it's put into the database:[Append db=xx]field1=[url][form_field1_value][/URL]&field2=[url][form_field2_value][/URL ][/Append]What happens here is any & inside [form_field1_value] get converted to %26, which is the URL-equivalent of &. WebCatalog see this and converts it back to & automatically at the point it actually gets written to the database. An '=' will also cause trouble unless you use this technique.So to make a fine point: literal ampersands are fine inside a database field (for instance, if you export a database from another source that happens to already contain & in the data). Having the & there is not going to hurt the database, nor is it going to mess up the *retrieval* of those fields from the database.The real issue we're resolving here is those times when a *browser* is involved in the process, such as those times when you are building an HREF, because the & has a special meaning inside an HREF, just like ?, /, =, and #. Since WebCatalog's embedded WebDNA contexts also use this syntax, you must also 'protect' your text with [url] when using embedded contexts. Basically a computer cannot tell the difference between an & *inside* your field, vs. one that delimits the beginning of a new name=value pair.Technical Support | ==== eCommerce and Beyond ==== Pacific Coast Software | WebCatalog, WebMerchant, 11770 Bernardo Plaza Court | SiteEdit Pro, PhotoMaster, San Diego, CA 92128 | Typhoon 619/675-1106 Fax: 619/675-0372 | http://www.smithmicro.com/ PCS Technical Support

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:

[WebDNA] New Webdna framework ! (2012) Sku numbers (1997) Re2: frames & carts (1997) Emailer Set Up (1997) Template Encrypt Speed (1998) Why WebMerchant not working? (1999) No luck with taxes (1997) searches with dash, period etc. (2000) Word search (1997) [Listfiles] vs Netfinder (1997) More on the email templates (1997) RE: Answer: WebDelivery downloads alias, not original ? (1997) Searching an Email database (1997) [WebDNA] Mondy morn... [date] question (2009) Time Tracking (2003) wc 2 pro users - sites, quotes wanted (1997) Emailer (WebCat2) (1997) [SHOWIF AND/OR] (1997) HELP WITH DATES (1997) Listserver problem (1997)