OK, lots of things here. I did miss that part of the output and the “…Interface to PC” line is present. I've attached a dummy file which is a straight save-copy of the original, with 1) special characters removed, 2) hard stops (“spaces”) replaced manually, 3) extraneous columns removed, and 4) some obvious changes to the actual data. In this file, the first 8 columns are the problematic fields, the others read in without problem. Row 7 (red font) has the original variable names, just for your info. I also looked more closely at the original log, it did say: “NOTE: One or more variables were converted because the data type is not supported by the V9 engine. For more details, run with options MSGLEVEL=I.” When I did that, there were a bunch of Notes although I don’t know if they’re relevant; they cover both problematic and non-problem variables: NOTE: VARCHAR data type is not supported by the V9 engine. Variable VAR3 has been converted to CHAR data type. NOTE: VARCHAR data type is not supported by the V9 engine. Variable Status_Reason has been converted to CHAR data type. Then I ran the dummy file and didn’t have any problems. So I tried another dummy but not taking the hard stops out (which would be more work for the 2nd crew). And that one also worked but… it accepted the field with a question mark that it had originally renamed to Var53. So I’m really not sure what’s going on there. Finally, the Excel file I use is a value-paste copy of the original, which does have some hidden code that I don’t know any other way to get rid of (the Community helped me figure that one out!). It’s looking like the simplest answer is going to be KurtBremser and Irackley’s approach of using validvarname=any and coding in the renames.
... View more