We are creating a listing system within ExactTarget using AMPscript powered forms, data extensions and Microsite Landing pages. An HTML form is used to add and edit "items" in the system which appear on these lists. When a new record (an item on the list) is created, it appears that HTML coding including links and markup work fine and nothing breaks. If the item is edited though (done through the same add/edit html form/landing page) data seems to move around between fields and get corrupted or changed. I suspect this is a result of "'s appearing within the @variables creating confusing between what is intended to indicate a data field from the extension vs. quotation marks within the text. Point is that when a new item is added, it is fine, but as soon as we try to edit the item through the form, the quotations get converted no longer displaying as intended and sometimes actually moving data around on the page. I'm hoping to find a means to format the text area field on the form to preserve the characters as entered though the solution may be different. Using a text editor for the text area has been suggested as a possible solution but for specific reasons is not an option at this time. Please let me know if this is too specific or not enough.

Support Tech Details: The text area is a simple text area set as

<div class="" title="the title here" data-toggle="tooltip"data-placement="left">
    Detail Description:
<textarea name="Details" class="form-control" cols="48" rows="5" maxlength="1800" id="Enter Item Details Here" value="%%=v(@Details)=%%">

The field in the Data Extension is simply a "Text" field with the 1800 char. limit. Upsert detail includes:

SET @Details = RequestParameter ("Details")


SET @UpdateEvent = UpsertData("Events_List", 1, "itemGUID", @itemGUID, "itemID", @itemID, "Details", @Details... etc.

(more fields are involved in the upsert but probably not required for this description. The UpsertData works fine, but the result is that if we use code to enter something like &quot;

When adding a new item and it will save and look fine. However, if we go back to that item to EDIT it (same form is used for edit upsert and add item) instead of &quot; appearing in the Textarea, the symbol " now appears. If that is saved (which will upsert) it now throws off the field information and can actually put data into incorrect fields. For other characters such as &copy; it won't throw off the data fields, and also adds the item as intended (in this case with a copyright indicia) but again if the page is edited, instead of the code, the copyright symbol appears in the text area, and if saved, will no longer render as intended on the items detail page.

I suspect this is a matter of "escaping" the characters but the solution may be encoding or formatting.

  • 2
    I think the difficulty here is, there isn't any code. What we don't know is how you are getting the data from the form, how it's being added to the upsert call, or anything else that might be happening here. There is no way anyone can give a credible answer. It will be a guess, wait for you to try it, then see if it worked. The question needs to show exactly what you are doing, otherwise it's just opinions on what it could be, not what it actually is. Commented Feb 5, 2014 at 12:55
  • Sounds reasonable, Today was a busy one between no electricty/wifi and hindered driving I was unable to focus on this. Either tonight or tomorrow I'll add in summary scripts that detail what is going on. - thanks for the suggestion.
    – Jonny Shaw
    Commented Feb 5, 2014 at 22:17

1 Answer 1


I think what will fix you problem is this -

<textarea name="Details" class="form-control" cols="48" rows="5" maxlength="1800" id="Enter Item Details Here" value="%%=v(@Details)=%%"></textarea>

When I add the value only, it shows up properly, but I think changing the html inside it is altering it, and displaying it as the ".

Here is a jsFiddle using something similar with jQuery.

Alternative Use something like this -

Replace(@content, Concat(CHAR(13), CHAR(10)), "<BR>")

Just modify the content as it goes into the DE. You can also utilize Base64Encode() Base64Decode() to store as a Base64 string in the DE.

  • I must be missing something, to me that textarea tag looks just like the one I submitted above. Is the suggestion to use javascript alerts to let people know there is something wrong? Was really hoping for something to make the characters remain as entered going to and from the database.
    – Jonny Shaw
    Commented Feb 7, 2014 at 15:36
  • The difference is in the code right above. You are using the @Details in the html and the value. The html is overriding the value. The character as the email is getting interpreted by the .val() call, and there for going into the data base in properly. The only way to make sure they go in correctly would be to do a find/replace as they go in, or perhaps encode the html before upserting. Commented Feb 7, 2014 at 16:01
  • I think that the function requires using @details in both locations so that when a user edits the item, the details appear prior to and upsert after edited though it is giving me an idea of using a different variable for the what initially displays vs. what is upserted. I think therefore that find and replace or encoding would work. If you have a suggestion for which encoding or if there is a find/replace within AMPscript (javascript is sometimes challenged here but is available as well) that might be fairly simple as well. A couple things to try, suggestions welcome...
    – Jonny Shaw
    Commented Feb 7, 2014 at 16:58
  • The fiddle shows that you get the same result adding it to the value or the html. You don't need to add it in both. The value when edited is how it will get passed when retrieved. Commented Feb 7, 2014 at 18:13
  • Frustrated as the team keeps pointing me in new directions and I'm not getting time allocated fix these issues and close these stacks! I hope to get back to this soon, I think the encode/decode will be the final answer. I'm also eager to see how that will impact character counts. Thanks Kelly!
    – Jonny Shaw
    Commented Feb 10, 2014 at 19:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .