I found a subtle difference with how some text files were importing into a program I’ve converted from Pan6 to PanX. To simplify it: make new databases in each, both consisting of two text fields, A and B. Then import (either via menus or programmatically) into each the following text file:
program, but
program,but
In PanX both records will be identical, with no spaces. In Pan6 the space before the first ‘but’ will appear in field B.
So far the impact of this on me has been trivial, but someone may find it more significant and sneaky to pin down. I don’t think I want the new behavior changed back to the old. But the fact that there is this difference should be documented somewhere, so I’m posting it here. Ideally it can be worked into Panorama’s documentation along with how to achieve the old behavior, if wanted. I presume such is possible although I haven’t thought out how yet.
Panorama X is importing the CSV data correctly according to the standard. According to the standard, if you want leading or trailing spaces, the data must be quoted, like this:
program," but"
Panorama X will now correctly match the way other programs handle CSV text, like Excel, Numbers, etc.
Another way of putting this is that this was a bug in Panorama 6, which has now been corrected. In fact, there were quite a few bugs in Panorama 6’s CSV handling, which have all been corrected by using a true parser instead of the simple minded import code that Panorama 6 used. (Plus, of course, Panorama X accepts Unicode text.)
I’d rather suspected this reflected Panorama X correcting Panorama 6, which is why I didn’t want it ‘fixed.’ I just wanted it documented somewhere on the short but sneaky list of X vs. 6 known differences, to consider when conversions don’t just work out of the box. And thanks for supplying the method for including leading or trailing spaces, when so desired.
I love that your using standards meant I no longer have to work around an old Panorama 6 cvs import bug: in which embedded quotes within the cvs ‘fields’ confused the parser to shift subsequent fields in those records one to the left. It took me quite a bit of effort, back in the day with Pan6, to figure out and code around my roughly 1/10000 records that did that. In X those records all imported to the proper fields. Although not necessarily character for character identically. Extra lines within a field in Panorama 6 were delimited with crlf(); in Panorama X just cr() is used. crlf() might have been the ‘standard’ back when you wrote Pan6 so that may not count as a Pan6 bug. When my conversions got close enough I programmed comparisons between what my Panorama X databases were producing and what the old Pan6 ones did with the same inputs and, I hoped, comparable programs. I was puzzled why some seemingly identical cells were one character smaller until I realized PanX wasn’t keeping those lf() characters.
Yes, this database’s data all originated on Windows and it continues to import new data from Windows. So Panorama 6 allowed and let stand the Windows CRLF. Which made sense as Panorama 6 was also on Windows then. But Panorama X automatically converts embedded CRLF to CR when importing CSV, which I trust is per the CSV standard for Macs. That answers my curiosity on this.