I don't understand why they wouldn't just use a portal with one note per record. Doing otherwise would seem to be a loss of functionality rather than a gain as they seem to think.
Why didn't you ask the FM programmer for more info.
I think your single field for all notes idea is heading for disaster, especially if they get to the point where you have to purge older notes. If you have to keep it that way, then structured continuous backups are a must. You want to keep everyone happy, how happy are they going to be if the whole field becomes corrupt?
You could put them as related records, and have an auto enter text field that consolidates all the notes thru a calculation. Then they can still view, copy, and find notes, just not edit. Any editing should be on the actual record, with a timestamp modify field.
I think the best thing to do is worry about data integrity, and ease of management for you. The functionality and user interface can be made for them as smooth as possible, but users should adapt to the best DB design and not the other way around. Just take an example of everything you ever used on a computer--other programs, iPhones, etc. They build it, we figure out how to use it. :)
Note that with a portal of related records, they can still search out specific notes, drag and drop, copy/paste etc just as they are now, but gain the ability to have each note time and creator stamped. You also gain the option to display the notes in your portal most recently added note first--which is often the most useful order for such a system.
"You could put them as related records, and have an auto enter text field that consolidates all the notes thru a calculation. Then they can still view, copy, and find notes, just not edit. Any editing should be on the actual record, with a timestamp modify field."
This was what I was thinking - glad for confirmation. I just wondered if there were other ways to accomplish the same goal.