| This post was kindly contributed by Avocet Solutions - go there to comment and to read the full post. |
I recently got a new computer with a new (to me) operating system—Windows 7. I’m one of those diehards who stayed with Windows XP (and even with Office 2003), refusing to switch to Vista. This is a big change. I feel slightly dazed and disoriented because everything works so differently.
So you can imagine how comforting it was when I got SAS Enterprise Guide installed (both EG 4.2 and 4.3) and found that everything looked familiar. More than that, everything worked! I was able to open my data sets and run my projects. Everything was the same as it had been on Windows XP…until I tried to edit a data set.
When I tried to switch to update mode, a window popped up displaying an error message telling me that the data set “cannot be updated because its encoding does not match the session encoding or the file is in a format native to another host, such as WINDOWS_32.”
At this point I should confess—what now appears obvious to me—that because Windows 7 is a 64 bit operating system, it makes sense that data sets from Windows XP (a 32 bit system) might need to be converted. At the time it was not obvious for a number of reasons. First of all, I have lots of experience switching from one version of Windows to another, and I have never before had to convert data sets. I figured a .sas7bdat file…was a .sas7bdat file…was a .sas7bdat file. Adding to the confusion is the fact that Enterprise Guide is still a 32 bit application even when running on Windows 7. More important, I had (as I have previously mentioned) already opened my old projects in EG without any problems. I could open my data sets. I could run my projects. Why should editing a data set be a problem when I could do everything else?
The problem, ironically, is that CEDA is so good.
CEDA (Cross-Environment Data Access) is the feature that allows you to access SAS data sets in formats that are not native to your computer. And it’s so good that it is practically invisible. And when you open a SAS data set in a Data Grid in EG, there is no SAS log telling you that SAS is using CEDA behind the scenes. CEDA allows you to view data sets, and to use data sets, but apparently CEDA cannot be used to edit data sets in EG.
Based on the error message, I figured I would need to convert my data sets, but an internet search turned up no confirmation of this. I had some guesses as to how to do it, but I wanted to be sure I knew the officially recommended method. I decided to contact SAS Technical Support.
The helpful person at Technical Support asked me a few questions, asked me to run a Data Set Attributes task (that’s PROC CONTENTS for you programmers), and then recommended that I use the Export task to export my data set using the Win_64 format and open it again. When I followed this advice, EG deleted the data set. That’s right the data set was completely gone.
Fortunately, restoring that data set was a simple matter. At that point, I decided that maybe trying my own method wasn’t such a bad idea after all. I ran this highly sophisticated program.
DATA ‘c:\path\filename‘;
SET ‘c:\path\filename‘;
RUN;
It worked! When I told the helpful person at Technical Support this, he replied that I could also use PROC MIGRATE.
LIBNAME oldlibref ‘c:\oldpath‘;
LIBNAME newlibref ‘c:\newpath‘;
PROC MIGRATE IN = oldlibref OUT = newlibref;
RUN;
This also works and has the distinct advantage that you can convert an entire library at once.
Then I received this suggestion from Chris Hemedinger: Use the Upload task in EG. This method also works but requires two steps since you must define the libref before you open the Upload task.
So there are at least three ways to convert your data sets for Windows 7: using a DATA step, PROC MIGRATE, or the Upload task in EG. The first two, of course, will work in Display Manager; all three will work in EG.
Notes added November 11, 2010
Everything I said in this post on September 20 is true, but a few clarifications are in order.
1) There is both a 32 bit and 64 bit version of Windows 7. If you are running the 32 bit version, then, of course, you will not need to convert your data sets to the 64 bit format.
2) It has been reported to me that it is possible to install the 32 bit version of SAS Foundation on a computer running the 64 bit version of Windows. If you do that, I am told, then you do not need to convert your data sets to the 64 bit format. I have not been able to test this myself because I am running the 64 bit version of SAS.
| This post was kindly contributed by Avocet Solutions - go there to comment and to read the full post. |