PC SAS and SAS/EG both open active SAS Sessions, but EG is actually a .NET application that caches project information and generated code, which is stored in the project file, unless you explicitly tell it to store the code in a separte .sas file.
Now, since PC SAS starts a local SAS session, as you work on stuff, stuff is kept in the SAS registry and in the SAS "WORK" library. Also, compiled code is kept in memory. This can cause what would appear to be strange behavior if you make changes to what you are doing. Some of the "remembered" stuff held in memory doesn't necessarily get updated.
With "import" with SAS EG, some things just can't get updated the way you want since you can't directly update the generated code. So, I have had to delete an "import", stop the EG session, and then start it up again and recreate the import to be able to make some changes.
I just looked at the documentation for Proc Import, that is not helpful.
You should be able to write a single data step with infile and input statements that will let you read in the Excel sheet directly without extra manual processing. You may need to use the ATTRIB statement in front of the infile and input statements to predefine the variables, their informats and formats, to help.
I've inherited code sets that make use of Excel spreadsheets, and know that they can be a pain. One of the spreadsheets of initial rows of header information that had to be manually deleted to insure the actual columnar information began in row 1 so that SAS would read it properly.