Aside from Kurt’s non sequitur, deathly silence. I discovered today that this is not a bug at all, but a “feature.” To quote the release notes for version 0.1.025
That’s wonderful if I’m exporting to Excel, but I’m not. I’m not “exporting” at all, I am bringing an up-to-date Pan 6 database into Pan X to do a File>Import>Import Database to bring my X version up to date. So every text field in which the Return key was used to make a new line now has \x0B as the “new line” character instead of the \x0A that was originally inserted. This wouldn’t be so bad if all new entries I made with the Return key also embedded \x0B and I could just count on that, but instead they insert \x0A, as they did in 6.
As I said in my original post, there are many places where a procedure needs to break out the lines in a text field that are separated by the Return key, but it can be a real mystery just what the separator character is, and whether my array( function is going to break it predictably, when my database is a combination of imported data and newly entered (or edited) data, and they don’t look any different.
Can Export/Import be made a little smarter to not automatically assume that the intent is export to Excel, especially (or only) in the case where the user is doing a direct database import?