There is no workflow that goes from the messages form to the staging form, so I'm not sure how a filter there will help. The email engine is going directly to the staging form to create that entry.
The magical email engine. Thanks, Susan On Tue, Oct 29, 2013 at 9:06 AM, Grooms, Frederick W < [email protected]> wrote: > ** > > What about putting a filter on submit of the messages form with a set > fields action to replace the return?**** > > ** ** > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Susan Palmer > *Sent:* Tuesday, October 29, 2013 8:56 AM > *To:* [email protected] > *Subject:* Re: v8.1 email engine - truncated incoming message**** > > ** ** > > ** **** > > Checked the db and the results were as you suggested:**** > > **** > > 08:50:57 SYS@st_REMp2 > show parameter NLS_LENGTH_SEMANTICS**** > > NAME TYPE VALUE**** > > ------------------------------------ ----------- > ------------------------------**** > > nls_length_semantics string BYTE**** > > So we're good there.**** > > **** > > The issue remains open.**** > > **** > > Susan**** > > **** > > **** > > ** ** > > On Tue, Oct 29, 2013 at 1:50 AM, Ars Lister <[email protected]> wrote:** > ** > > ** **** > > One of the things about Oracle with 3999 varchar is that you have to make > sure it is resolving as BYTES rather than CHAR. The type of behavior you > are describing can happen when the distinction is not made in Oracle by > your DBA. There may be other issues like the field length in the staging > form, or intermediary out-of-the-box workflow that triggers before the > workflow that pushes the value to the appropriate staging forms. But have > your Oracle DBA check the following parameter: > > NLS_LENGTH_SEMANTICS=BYTE > > It is often set to CHAR, which would be a mistake and it can cause > corruptive data issues. Hopefully that isn't the case, but if it is, have > him/her change it to BYTE as soon as possible.**** > > **** > > Good luck!**** > > ** ** > > On Tuesday, October 29, 2013 12:03 AM, Susan Palmer <[email protected]> > wrote:**** > > ** **** > > Hi everyone,**** > > We've started receiving incoming emails from a customer. The email engine > retrieves them and I see the full message in the AR Email Messages form. > The template in the email contains the form (staging form) that the message > should populate. And it does populate the staging form, mostly.**** > > The description field does not populate completely in the staging form. > It does in the Messages form. If there is a 'return' in the description, > in the staging form no data appears after the 'return'.**** > > I have a support ticket in but no solution in the last week. I've > suggested to the customer to use <br> in their tickets that are populating > the template that comes to us but it was not received well. We do plan on > testing that Tuesday.**** > > We have been receiving automated incoming tickets from some internal > systems for years but those all have single line descriptions so there is > no 'return' to deal with, so I don't know if it was working the same on > v7.5. **** > > The field itself is a 4000 char field. Nothing else special about it. > Full permissions for anyone to write. The user that is contained in the > template has full basic permissions, fixed license. **** > > I take the info in the staging form record, create a HT retrieving > additional information from a Site record to make a complete HT record. > Since the staging form record doesn't have the full description there's no > opportunity to try and manipulate the 'returns' with workflow. **** > > It's almost as if the email engine itself is truncating the contents.**** > > Has anyone seen this also? What was the solution? Any help would be > appreciated. > > Thanks,**** > > Susan**** > > Susan Palmer**** > > ShopperTrak**** > > 233 S Wacker 41st Floor**** > > Chicago, IL 60606 > 312-529-5325**** > > [email protected]**** > > ARS v8.1**** > > Oracle 11g**** > > Linux OS > ** > ****** > > ** ** > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
