Hi, I found that the simplest route for me when working with multi-line field data was to pre-parse the data on storage and post parse it on extraction, by changing the 'cr''s to either another seldom used character or html (eg. '<br>').
So the database code before the INSERT/UPDATE would replace and cr's with '<br>', and once a SELECT is done either a single function to replace the '<br>'s with cr in all the data returned (possibly multi row) or to do the replace at the usage of the individual row/field. Doing it this way means that the database manager (Postgres/Mysql/Sqlite) doesn't really know or care about multi-line data. But the code handling the data should be carefully constructed to make sure that there are no instances of the data getting through to the end user (view OR edit) with the replaceable characters in. Obviously if you are using actual html content then it's even easier - simply replace ALL cr's with empty on write. And replace '<br>' and '</p>'s with the same AND a cr (for editing use). The whole process comes down to a couple of lines of code in the end and making sure you document which fields you do a morphing of the data in - so that it's easier to remember in a years time ;) - if necessary! Hope that helps a bit, Dave -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/thinking-through-parsing-multi-line-database-commands-with-cr-in-the-data-tp4665431p4665448.html Sent from the Revolution - User mailing list archive at Nabble.com. _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
