Formatting Notes Using eConnect 2010 - Challenge!
Community Member
Microsoft Employee
Like
Share
Report
Just when I thought I was comfortable with Dynamics GP integrations, along comes eConnect 2010.
The change from COM and DTC to a Windows Service took a little while to understand, but I've adjusted and am now pretty comfortable with the service and how to troubleshoot it.
Using eConnect within Visual Studio is very similar, except to a few changes to the final call to eConnect, but that wasn't difficult to accomodate.
But now I've run into a change that has me stumped for the moment. It's minor, but as with many "minor" things, it's an annoyance that just seems to be challenging me to figure it out and find a solution.
When importing notes into GP using eConnect 9 and 10, I have previously used "\r" or vbCr (carriage return) to produce line breaks in the note text. Worked like a charm.
When I had to send a note line break using GP 10 Web Services, I figured out that you need to send the UTF-8 escaped version of carriage return, which is & #13. (I've had to add a space to prevent the blog publishing from thinking it is HTML)
Great, problem solved, mission accomplished, non-issue.
But then comes eConnect 2010. When testing an integration that I upgraded to 2010, I noticed that my notes now had the vertical bar in the note instead of a line break. Hmmm.
I tried \r, \n, and \r\n, but all produced the same result. So then I tried & #13, but that just put the literal text of "& #13" in the note!
Just to make sure I wasn't going crazy, I queried the text of a GP note with manually entered line breaks and was able to confirm that "\r" is still the line break being used and stored in SQL.
So now I'm stumped. I need to do more testing with \r to see why that doesn't seem to work, and how that value is being stored in the database when it is saved by eConnect 2010. I'm guessing it is escaping the character somehow and that is causing the problem, but I haven't had time to trace the SQL or query the resulting note text to figure out what character is being stored.
If any eConnect 2010 gurus out there know the answer, post a comment and impress us!
The change from COM and DTC to a Windows Service took a little while to understand, but I've adjusted and am now pretty comfortable with the service and how to troubleshoot it.
Using eConnect within Visual Studio is very similar, except to a few changes to the final call to eConnect, but that wasn't difficult to accomodate.
But now I've run into a change that has me stumped for the moment. It's minor, but as with many "minor" things, it's an annoyance that just seems to be challenging me to figure it out and find a solution.
When importing notes into GP using eConnect 9 and 10, I have previously used "\r" or vbCr (carriage return) to produce line breaks in the note text. Worked like a charm.
When I had to send a note line break using GP 10 Web Services, I figured out that you need to send the UTF-8 escaped version of carriage return, which is & #13. (I've had to add a space to prevent the blog publishing from thinking it is HTML)
Great, problem solved, mission accomplished, non-issue.
But then comes eConnect 2010. When testing an integration that I upgraded to 2010, I noticed that my notes now had the vertical bar in the note instead of a line break. Hmmm.
I tried \r, \n, and \r\n, but all produced the same result. So then I tried & #13, but that just put the literal text of "& #13" in the note!
Just to make sure I wasn't going crazy, I queried the text of a GP note with manually entered line breaks and was able to confirm that "\r" is still the line break being used and stored in SQL.
So now I'm stumped. I need to do more testing with \r to see why that doesn't seem to work, and how that value is being stored in the database when it is saved by eConnect 2010. I'm guessing it is escaping the character somehow and that is causing the problem, but I haven't had time to trace the SQL or query the resulting note text to figure out what character is being stored.
If any eConnect 2010 gurus out there know the answer, post a comment and impress us!
This was originally posted here.
*This post is locked for comments