I am using a well known piece of code to read an excel work book into SAS. The SAS code is called from Excel and then proceeds to open the required SAS work book and read the data into a SAS data set. The problem that I have is that while the code is being read in, we can see how SAS runs through the data set.
Is there a way to hide this? I realise the excel work book needs to be opened, but I would prefer it to stay minimised so that I don't see all the jumping around the work book. Furthermore, if you click anywhere during the read in process, the process fails. I am not sure if hiding the work book will also fix this issue?
Using SAS 9.3 and Excel 2010 this worked for me, it's app.minimize (not apps.minimize()).
However, you still cannot work with your computer.
options noxwait noxsync;
x '"C:\Program Files (x86)\Microsoft Office\Office14\EXCEL.EXE"';
data _null_;
z=sleep(1);
run;
filename cmds dde 'excel|system';
data _null_;
file cmds;
put '[open("C:\_LOCALdata\air.xlsx")]';
x=sleep(1);
run;
data _null_;
file cmds;
put "[app.minimize()]";
x=sleep(2);
run;
Related
I have a question relating to the differences between the 32 bit and 64 bit versions of Excel and VBA.
I am working in Office 365, 64 bit. (I am using 64 bit because I ran into memory issues and as a test, to see if 64 bit works for our company). I am working on an Excel file which has a lot of VBA code used to gather product properties from SQL, calculate parameters from these properties, and output everything to another SQL database. In addition, the Excel file outputs PDF files.
The Excel file is stored as a template, so that users can open the template and save the new file to their respective workspace. At the moment, the users are using Office 365, 32 bit.
When I open the Excel template, Excel closes itself. It seems to crash before calculating the parameters on the new file. There is no error message; in the lower-right message box I can see that Excel doesn't get to the calculating stage.
However, when the other users open the file in 32-bit Excel, everything is fine.
I am not using pointers (no PtrSafe) and no LongLong variables.
I also have no compile errors.
I am currently rebuilding the Excel file by saving it as a file without macro's, and then copying the VBA modules - a different site mentioned the VBA code may be corrupt. I am halfway through adding macro's, and the error pops up again; the VBA code I have added last has been in use for about a year so I am tempted to exclude it as a culprit.
Where would you suggest I look to find the problem?
You're absolutely right of course. I have gone back to the last working version and began adding a text logfile, which would log the start and end of each procedure. I got lucky as the file crashed as I was doing this, and the logfile pointed me towards a procedure seemed to be working, until the right conditions were met for it to crash.
The procedure itself accesses global variables which were not initialised. I didn't catch errors that could occur properly. For some reason, this works fine in x86 Excel, doesn't trigger any problems in the compiler or during debugging but crashes in x64 Excel when enough memory is used.
Gekozen_Assen is the name of a global variable. It is a dictionary which contains information. I had tried to use .Exists as a method to test if the required item in the dictionary exists, but this doesn't work if the dictionary isn't initialized at all.
The errorous code:
GetFromGlobal = ""
If Global_Dictionary.Exists(Answer_Type) Then
GetFromGlobal = Global_Dictionary.Item(Answer_Type)
Else
GetFromGlobal = "Error!"
End If
Instead I should've been using "Is Nothing", the fixed code below:
If Global_Dictionary Is Nothing Then
GetFromGlobal = "Error: Dictionary not initialized"
Else
If Global_Dictionary.Exists(Answer_Type) Then
GetFromGlobal = Global_Dictionary.Item(Answer_Type)
Else
GetFromGlobal = "Error: Dictionary item not found"
End If
End If
I have recently been experimenting with perl and some modules to read Excel files and in particular the format of thier cells.
For example I wrote a piece of perl code that used the module ParseExcel to read a cells background colour. However while testing I noticed that for certain files the colour returned by my perl program did not match the colour reported by Excel. Eventually I found the reason for this was that the file I was reading was a .xls file saved in compatibility mode. Basically the creator of the file had used the functionality of Excel .xlsx type files (2007+) to colour some of the cells and then saved the file with the old .xls file extension that did not support the colours chosen.
So my question: Is there any way to tell whether a given .xls file (or any other old Excel file format) has been saved in compatibility mode without usung Excel to find out? The reason I ask is that I am working under a linux environment and can't use any windows tools to analyse the files.
Furthermore, if one could identify that a given Excel file has, indeed, been saved in compatibiity mode is there any way of knowing how the original colours were mapped to the ones that my program is telling me?
Many thanks for any help on this.
I do not think that you can do this using Spreadsheet::ParseExcel. I have tried saving an xls file with a color from an .xlsx and saving it with 2003 compatibility. Then comparing it with an empty .xls of 2003 and I do not see any difference in my files.
You can try the following code to debug it with your own files trying to find a difference that you could use:
use strict;
use warnings;
use Spreadsheet::ParseExcel;
use Data::Dumper;
use JSON;
use Test::More tests => 1;
my $file_1 = 'test_xls.xls';
my $file_2 = 'compat_xls.xls';
my #files = (
$file_1,
$file_2,
);
my #workbooks;
foreach my $file (#files){
print("\n\nReading $file\n");
my $parser = Spreadsheet::ParseExcel->new();
my $workbook = $parser->parse($file);
# print Dumper($workbook->{PkgStr});
delete $workbook->{PkgStr};
delete $workbook->{File};
delete $workbook->{Worksheet}->[0]->{MinRow};
delete $workbook->{Worksheet}->[0]->{RowHeight};
delete $workbook->{Worksheet}->[0]->{_Pos};
delete $workbook->{Worksheet}->[0]->{MinCol};
delete $workbook->{Worksheet}->[0]->{MaxCol};
delete $workbook->{Worksheet}->[0]->{MaxRow};
delete $workbook->{Worksheet}->[0]->{Cells};
delete $workbook->{Format}->[62];
push #workbooks, $workbook;
}
my ($ok, $stack) = is_deeply($workbooks[0], $workbooks[1]);
my $diag = explain($stack);
print(Dumper($diag));
I wish to write to Excel on my PC a "big" matrix of p rows and c columns, e.g.
3,000 rows and 20 columns. But it's not easy, and I'm wondering if I can simplify it by using a fixed number for rows and columns instead of:
array mat {&periods,&columns};
Right now, I'm on the free version of SAS called "SAS University Edition", which has only community help.
I would like to output it to Excel, but using VMWARE on a PC to get SAS Studio to run, you can't write directly to disk (although there is a myfolder).
I tried this, but got this error log:
proc export data=WORK.CPAPMONTE1
file= "/folders/myfolders/outfile1.xlsx"
DBMS=xlsx
;
run;
ERROR: XLSX file can not be created -> /folders/myfolders//outfile1.xlsx. Make sure the path name is correct and that you have
write permission.
ERROR: Too many variables for the output file
I figure that the 2nd error is just due to the first error, which has a // instead of a /
I have defined a special folder for my data in SAS University Edition as:
/folders/myfolders/CPAP1
but I haven't figured out how to point to there
You can write directly to disk, you need to set up a shared folder similar to myfolders and then you reference its as
/folders/myshortcuts/myname
The folder and shortcut must be exactly correct, and all need to be lower case as it's case sensitive. If you have myfolders set up, all you need to do is right click on the folder>Properties and you'll get the path to the folder. Use that in your export. A similar process can be used for the custom shared folder you set up.
SAS University Edition Help Center/FAQ
https://support.sas.com/software/products/university-edition/faq/main.htm
Your specific question - How do I create a folder shortcut to my existing SAS files?
https://support.sas.com/software/products/university-edition/faq/shared_folder_access_existing.htm
matlab (2015b) in my new notebook ThinkPad function xlsread/ xlswrite not work
for every exist excel file， xlsread not load the data
xlswrite also not work in every path
error use xlsread (line251)
catch exception
if isempty(exception.identifier)
exception = MException('MATLAB:xlsreadold:FormatError','%s', exception.message);
end
throw(exception);
the method import data also not work for excel file。
I found this answer in
https://cn.mathworks.com/matlabcentral/answers/282688-why-my-excel-file-can-not-be-read-by-matlab hope it can help you:
Who has problem to read excel file, can follow this order.
1- open the excel> file, >option, >add in, manage then select COM ADD IN, and clear everything (unchecked). everything should be cleared (unchecked).
2- restart the PC, and open the matlab.
3- perform xlsread command.
NOTE: for those people who use foxit pdf reader, it is potential to face this problem, so follow mentioned order.
NOTE: sometimes by using the matlab, configuration of excel is changed in unknown way, therefore there is no way to open the usual excel file in windows by double click.
So, open excel from desktop icon, file> option,> advanced,> general and then make clear (unchecked) "the ignore applications that use dynamic data exchange (DDE)". (same information for NOTE 2: https://support.microsoft.com/en-us/kb/3001579) these are some error for excel worker with matlab and related command.
Does anyone know a workaround to make excel files work in SAS when their is a bit discrepancy? My Microsoft office applications are 32 bit, and I have a downloaded version of SAS that I got for free while in school. The problem is that the SAS is 64 bit, and doesn't work with excel files. Is there an easy way to get around this?
If you have SAS 9.4 then you can read and write XLS and XLSX file directly.
Use PROC IMPORT.
proc import datafile='myfile.xlsx' out=mydataset dbms=xlsx ....
Or even a libname.
libname mydata xlsx 'myfile.xlsx';
proc copy inlib=mydata outlib=work; run;
Depending on your version not all features of XLSX are supported. You can download PCFileServer to get around these and use DBMS=EXCELCS. You also have the option of using SAS University Edition for free. Both should be under similar licence, only valid for learning purposes.