I’ve recently been upgraded from SAS 9.2 (32-bit) to SAS 9.3 (64-bit) with Office 2010 (32-bit).
Almost everything seems to work fine, however I can’t get SAS to send emails without a remote submit!
If I submit locally, I get the message “ERROR: Undetermined I/O failure“ and a pop up from Excel stating “Either there is no default mail client or the current mail client cannot fulfill the messaging request. Please run Microsoft Outlook and set it as the default mail client.”
My outlook is the default mail client!
Does anyone know why this is?
If I do remote submit, I then I can’t attach files stored on my desktop or shared drives!
Sample of my code is below:
rsubmit;
filename outmail email
subject="Cars (secure)"
TO= ("email")
CC= ("email")
ATTACH= "C:\\Book1.xlsx";
DATA _NULL_;
FILE outmail;
PUT "Hello All,";
PUT " ";
PUT "Please find attached the Cars file.";
PUT " ";
RUN;
Any help is very much appreciated.
The issue is with the local configuration. There are three different approaches you can take:
1 - Click Start / Control Panel / Programs / Programs and Features / Microsoft Office 2010 / Change / Repair / Continue. Now follow the repair process.
2 - Click Start / Type & select "Default Programs" - follow the on-screen instructions to set Outlook as the default.
3 - Browse to the location below, and delete MSMAPI32.DLL:
C:\Program Files\Common Files\System\MSMAPI\1033
The file will be recreated once Outlook 2010 relaunches.
Related
I am getting the below error when i am running 'proc hpsplit' in sas to create a decision tree.
sas error: hpspit was unable to open the rules file for output
My code is -
proc hpsplit data=sashelp.hmeq maxdepth=7 maxbranch=2;
target BAD;
input DELINQ DEROG JOB NINQ REASON / level=nom;
input CLAGE CLNO DEBTINC LOAN MORTDUE VALUE YOJ / level=int;
criterion entropy;
prune misc / N <= 6;
partition fraction(validate=0.2);
rules file='hpsplhme2-rules.txt';
score out=scored2;
run;
But if I change the statement 'rules file' declaration to the below -
rules file="%sysfunc(pathname(work))/rule.txt";
It runs fine in this case but then i am unable to view the rule.txt file.
Please suggest a way i can view the file or any other way i can proceed.
rules file='hpsplhme2-rules.txt'; will not necessarily write to work; it depends on what your default directory is in the current session. It's usually not WORK in my experience. If you're running SAS in DM mode it's whatever is in the bottom right of the window (for my installation the default is my User directory, i.e. C:\Users\myusername). But it can be anywhere, just depends on where your admin set it up to be, and if you executed any cd commands in the code.
The answer here is to fully qualify your path name. If you're running this on a server, make sure that path is a path you can write to from the server (not "c:\something" probably).
It could be as simple as
options noxwait noxsync xmin;
%sysexec
start
"Preview output"
"%sysfunc(pathname(WORK))\temp.txt"
;
If simple does not work the solution depends on your SAS client and the SAS host security policies.
I am using MAPISendMail() in an MFC application, and am having a problem that webmail clients sometimes receive a winmail.dat attachment, instead of the "real" attachments.
I have researched a lot, and have found that others are experiencing this problem too, but have not found a solution.
I believe that the problem may be in my MapiFileDesc structure, in which I leave the lpFileType member pointing to NULL, in order to have the mail program (In my case Outlook 2010) determine the file type automatically.
lpFiletype is a MapiFileTagExt structure, and the documentation says this:
A value of NULL indicates an unknown file type or a file type determined by the operating system.
So I believe this should work for common types, such as JPEG or GIF and such.
I read that the winmail.dat is caused by Outlook sending the mail encoded with the ms-tnef encoding, which is proprietary to Microsoft. However, when sending the email, Outlook shows "HTML" as highlighted, not RTF.
Has anyone encountered this problem and properly solved it?
Sending via SMTP and such is not an option, because the user should have a copy of the message in their Sent Items folder.
Using the Outlook object model is not an option, because that would require the user has Outlook installed, and not any MAPI compatible client.
I was having similar issue.
I found a KB article that has interesting information in "One-Off Addressing" section, saying that when address is provided in the format [SMTP:SMTP Address] - then e-mail is always sent in rich text format.
For me the fix was not to set "Address" property of MapiRecipDesc object at all. Instead I put the address in Name property. The opening dialog then does not resolve the address at first, but it resolves it right before sending and then it is not sent in RTF!
I even got it working with recipient's name together with address:
MapiRecipDesc.Name = "Firstname Lastname <mail#address.com>";
I, too, was getting all attachments as WinMail.Dat files for the jclMapi.JclEmail, InternalSendOrSave routine, which is called by jclEmail.Send.
What I did was essentially follow jtmnt's answer and changed:
RealAddresses[I] := FAddress; //do not add the Recipients.AddressesType + AddressTypeDelimiter
and I changed:
lpszName := PAnsiChar('"' + AnsiString(RealNames[I])+'" <' +
AnsiString(RealAddresses[I]) + '>');
lpszAddress := '';
This worked so that I no longer was sending WinMail.dat files as attachments, instead the intended PDFs and MP3s were being sent.
What I really want to report is that I was using an OLE routine that was working fine in Windows 7 and stopped working in Windows 8. Thus, I started looking at the MAPI solutions but found this problem with Winmail.dat files being attached. I could not find any mention of this issue with OLE (with Outlook) not working properly in Windows 8.
(Both:
OutlookApp := GetActiveOleObject('Outlook.Application') and
OutlookApp := CreateOleObject('Outlook.Application')
were no longer working in Windows 8, but continued to work fine in Windows 7.)
Thanks for the solution. Thought you might want to know how to apply it to the jclMapi code and this issue with OLE in Win8.
Curious in Outlooks behavior is it does matter what length the domain name of the recipient has! If the e-mail address domain is 12 characters or more (I don’t know what the limit exactly is), then we face the problematic TNEF coding.
So: a#hutsfluts.nl goes wrong. While abacadabraandmore#hf.nl will result in plain text encoding.
I guess this is not by design….
The solution mentioned above:
Put the recepient e-mail address in MapiRecipDesc’s lpszName and let the lpszAddress point to an empty string (NOT null!) solves the problem.
Don’t ask me why, for I have no clue why this would influence the encoding.
This is related to a previous thread I started, but it deals with a method that actually works.
I have created a VBScript that ColdFusion executes and sends a fax to a specific number. The following is the VBScript I wrote, taken from a Microsoft TechNet Site:
Set objFaxDocument = WScript.CreateObject("FAXCOMEX.FaxDocument")
Set objFaxServer = WScript.CreateObject("FAXCOMEX.FaxServer")
Dim JobID
objFaxServer.Connect("")
objFaxDocument.Body = "C:\*PATHNAME*\testfax.pdf"
objFaxDocument.DocumentName = "My First Fax"
objFaxDocument.Priority = "2"
objFaxDocument.Recipients.Add("8885551212")
objFaxDocument.AttachFaxToReceipt = True
objFaxDocument.CoverPageType = "1"
objFaxDocument.CoverPage = "generic"
objFaxDocument.Note = "Here is the info you requested"
objFaxDocument.ReceiptAddress = "test#test.com"
objFaxDocument.Subject = "Today's fax"
objFaxDocument.Sender.Title = "Mr."
objFaxDocument.Sender.Name = "Test Man"
objFaxDocument.Sender.City = "Test City"
objFaxDocument.Sender.State = "FL"
objFaxDocument.Sender.Company = "Test Company"
objFaxDocument.Sender.Country = "USA"
objFaxDocument.Sender.Email = "test#test.com"
JobID = objFaxDocument.ConnectedSubmit(objFaxServer)
MsgBox("The Job ID is :" & JobID(0))
objFaxServer.Disconnect()
The following is the ColdFusion code I use to execute this vbscript:
<cfexecute name="C:\Windows\System32\cscript.exe"
arguments="C:\*SCRIPTPATH*\test.vbs">
</cfexecute>
On a machine that has Windows Server 2003, this successfully sent the document to the Windows Fax Service application, and stored the fax correctly in the outbox. However, when I attempted this on Windows Server 2008, it does not work. It should be noted that while the same version of ColdFusion (8) is being used, the 2008 machine is 64-bit while the 2003 is 32-bit.
This may have been answered elsewhere (if so please guide me) but I have had the hardest time with this and there are not many successful solutions out there for me to find. I know I'm missing something but I don't know what. Can anybody help?
This is difficult to answer that precisely because you don't quantify "does not work". In what way does it not work? Is there an error on the screen? Is there an error in the log files anywhere? Does the VBS get called, but does it then fail (it could be a vagary of how it's being called)?
That said, I suspect it's a case that the service account that CF is running under doesn't have permissions to access or execute the VBS, or some other resource the VBS uses.
If you login as the user CF uses, can you execute that statement from a command line?
Crystal Reports seems to have an 80 section per group limit
Environment:
Microsoft Windows XP
Professional
Version 2002
Service Pack 3
Crystal Reports XI (Release 1)
Calling the Crystal Reports Engine crpe32.dll version 11.0.0.1445
Via Crystal VCL 11 libraries
Via Borland C++Builder 6 Enterprise Suite Version 6.0 (Build 10.166)
I found the report containing 86 sections (in one group)
ran just fine using the Crystal Reports XI exe found at
C:\Program Files\Business Objects\Crystal Reports 11\crw32.exe
However, when I called the same report from an executable compiled
using Borland C++Builder -> VCL calls -> crpe32.dll
IT DID NOT PRINT.
I spent many frustrating hours debugging the exe.
I used the divide and conquer debugging approach and devised
a state machine that would do the following while logging every
state along the way:
Load the Engine via LoadEngine;
Open the Engine via OpenEngine;
Open the PrintJob via OpenJob;
Close the PrintJob via CloseJob;
Close the Engine via CloseEngine;
Unload the Engine via UnloadEngine;
I found that the report errored out at OpenJob
with Crpe1->Status() status crsJobFailed
Crpe1->LastErrorNumber() was "505: No print destination specified"
Here's the play by play (I output this to a file):
LoadEngine() started
LoadEngine() completed. The handle to CRPE32.DLL is: 728956928
EngineOpen() started
EngineOpen() completed. Engine is already opened.
JobIsOpen() started.
JobIsOpen() completed. The PrintJob is open.
Execute() started
Status() crsJobFailed
Execute() failed.
Error state.
LastErrorNumber 505: No print destination specified.
C:\REPORTS\ProblemReport.rpt
Please first call PEOutputToWindow or PEOutputToPrinter!
Execute <PEStartPrintJob>
Finished state.
Back to the report:
Deleting some /*comment*/ sections from the report brought the number of
sections down to 78 and voila ... the report printed out just fine from the
executable compiled on Borland C++Builder -> VCL calls -> crpe32.dll
My conclusion:
Avoid creating over 80 sections in a group.
As a workaround, you can add another group having
the same GROUP BY column (essentially, repeat the
same group) and create all the extra sections needed
in the new group (the repeated group).
It's the equivalent of writing the following SQL
SELECT
column1
column1
FROM table
GROUP BY
column1,
column1;
Has anyone else had this problem?
If yes, what solution have you devised?
How can the popup window ("getting started with sas") be prevented from displaying when opening a second SAS session (ie when a 'work' profile is used that does not contain your normal settings) ???
running
proc options internal; run;
reveals the TUTORIALDLG option, but I do not know the syntax to set this option at 'invocation' - (presumbably in the .CFG file..)
Just add the line
-NOTUTORIALDLG
to your config file or if you use the command line to start sas you can add the line to the startup command. If you need to find the location of the config file your session is using, submit this command:
proc options option=config;run;