v15.2 - Notes - "Rich Text" loss of vbCrLf? [SORTED!]

[Paolo F Cantoni]

As we know, the Note column in (for example t_object)  is a "Long Text" format (formerly Memo) in a typical .eap/.eapx repository and varchar(MAX) in SQL Server.  Via the EAUI (pun intended) we can add "Rich Text"/"HTML" adornments to the text.  These are stored in an HTML-compatible form within the column.
If one displays the column (say with MS Access), we can see the HTML within the "plain text".  When we wich to display the "rendered" output we normally just set the "Text Format" property of the item to "Rich Text" and we get the adornments displayed directly (bolding, colour, underline, italic etc.)

This has worked fine for me for a decade.  But yesterday, when I set the property to "Rich Text", I did get the adornments, but "at no extra charge", I lost ALL the line endings in the query output!  That is, the output was one continuous stream of characters.  Any blank lines or line endings disappeared.

Investigation showed that the line endings could be restored by post-processing the field with a function that replaced all instances of vbCrLf (in this case, for Visual Basic) with <br>.  NOTE: The repository was a SQL Server repository, but I don't think that affects the problem.

Is anybody else seeing this?  Should it work like this?  I don't recall seeing this behaviour before. 
It's not clear where the issue is.  EA, SQL Server, MS Access.   (adding <br> to the Note by direct column update will render the "<br>" visible in the Note)

TIA,
Paolo

[qwerty]

All I can say is that the Note(s) column contains a Sparx proprietary format. It's not HTML (though it might resemble that). You need to use the GetTextFrom (or what it was called) API operations of the repository class in order to get propert HTML, RTF or TXT.

q.

[Geert Bellekens]

I haven't seen any weirdness like that.

Geert

[Paolo F Cantoni]

I haven't seen any weirdness like that.

Geert

Thanks, Geert,

I want to stress this is about direct access to the DB via SQL, not using any API available functionality (such as GetFormatFromField).

We may have to resort to using such functions to generate specific properties.

Paolo

[Eve]

The internal notes do not store <p>/</p> or <br/>. If you are passing the results to something that expects html, it will remove any line breaks.

[Paolo F Cantoni]

The internal notes do not store <p>/</p> or <br/>. If you are passing the results to something that expects HTML, it will remove any line breaks.

Yes, Eve, I've recently figured that out. 

The problem seems to be in MS Access - it behaves weirdly when presented with "formatted" text (of various kinds). 
We've taken the option of specifically creating properties that are populated with the output of GetFormatFromField() which Access handles correctly when the output is generated in HTML format.

Sorted!

The question of whether EA should hold "real" HTML rather than the half-way-house it currently does is moot.  As we've now discovered, "you can't cross a chasm in two steps..."

Paolo