I think all approaches mentioned are applicable.
It would depend more on functional requirements and programmers preferences, because as Jane mentioned, thanks for the example and results by the way, there are ways where disk usage is optimized and hopeful perfomance too.
With functional requirements I meant that with Douglas suggestion it would allow remarks traceability (users and time stamps), and would imply a slighty different user interface (INSERT,CHANGE,DELETE related remarks), while Mike/Sean suggestion, the Remarks Text Field can be implemented transparently to the user, hidding details of how it is stored.
Here it is a related thread:
https://clarionhub.com/t/pervasive-scalable-no-memo-change-to-blob-but-how-can-browse-show-blob/6046
You can see there other benefits of using a VARCHAR on the database and CSTRING on Clarion istead of a BLOB for easier access to the data and using the field directly on the template prompts. A thing to monitor if using a large string on a VIEW (Browse Column/HotField) is that POSITION(view) used on browse class works fine. See PTSS 42989 and this thread: https://clarionhub.com/t/windowmanager-update-calling-browseclass-updateviewrecord-rc-errorcode-error-78-invalid-number-of-parameters/5600/2
But I think with the proper unique keys on other fields it should work fine.