Switched to   %put &start_dt; %let unixsrv= misci01p.unx.sas.com 8581; options comamid=tcp remote=unixsrv; signon unixsrv username='spndac' password="Harker321!"; %syslput start_dt=&start_dt; rsubmit; endrsubmit; signoff unixsrv; Which It seems should be the spawner port. However, the code run without an end.   Could be less problematic to create a table on the local session with the macro values, and export it to the server session? But again, how to export that ... View more

@dcortell wrote: Hi all   With the below code I'm supposed to create a set of excel files, formatted, including the original columns headers, and with the column "url" working as link to click on within the excel.   However, While the excel files get properly created in terms of formats, I get two not wanted results:   a. It seems that the columns headers are not used. Instead the proc report show the column "labels". Not sure of the reason behind.   Your Proc Report code does not show any "column headers" set. So the default is the variable label, or without a variable label the variable name. If you want a specific column header other than the default that should appear in the COL statement or a DEFINE statement for the variable, which you didn't supply for most of the variables. So you get defaults.     The documentation says that the URL option for Call Define only affects ODS HTML, HTML5, RTF, PDF, PowerPoint, EPUB destinations . Since you are sending the output to tagsets.excelxp, which is XML output then don't expect the link to work. I don't create xml with hyperlinks so I am not sure what you may need to do.   Note that it is very poor idea to lie to computers in general, and may be related to getting incorrect output. You generate tagsets.Excelxp (XML) output but name the file with an XLS (not even XLSX extension) which means that there are all sorts of potential disconnects between the expected binary file layout from XLS naming and the XML content. You may find things are at least more consistent when you name the file with an XML extension, then the program opening the file has a better chance of appropriate conversions. ... View more

Your particular error is going to be related to something prior to the Proc ODStext.   Look closely at the log above that error for something that didn't finish as expected.   My suspicion is that the proc export or the filename outbox may have an issue, but that's guess.   ... View more

Hi Chris   - the ods listing were there as residual of an initial version of the code. however, also without it the results do not change   - i have tried different styles, htmlblue, sasweb, a personalized one..the result it is the same. Grey background in some cells, some cells do not receive the red-yellow-orange format   - I tested the style=minimal. The result is that grey cells disappear, but I get the following weird results in some cells of the proc tabulate outcome:        - still some cells do not receive the heat format    - one of them get strange markups   The output are ok where they generate outside an email ... View more

No connection. You just watch data at two different side. ... View more

OK. You are right. EXACT test take care of this situation. ... View more

First of all, I see the problem is you are trying to execute Proc Sql within from %test macro within proc sql in following steps. You need to only consider select statement.Please check first. ... View more

It is hard to read the SQL code you posted, but the error message does not appear to be related to either the logic of your SQL step or the logic in your attempt to write the fixed column data file.  Instead it looks like you have just referenced variables that do not exist in your data.   As @data_null__ pointed out your SAS log shows variable names using name literals that appear to have spaces or other non-printing characters as part of their names.  Why do your variable names need name literals? What is the source of these names?  Can you rename them to more normal names that use only alphanumerics and underscores?    You need to find the source of the invalid variable names that the error is complaining about. Usually you do this by trying to reduce your example to miminal set of code that generates the error.   Can you run a PROC CONTENTS on the data and see what variable names the data actual have?  You might try just running a simple report like PROC MEANS or PROC FREQ on one or two of the variables to make sure you can actually reference them in any way.   Once you have gotten past that issue then you can look into how to generate fixed format text file.  Note that you do NOT need to use SQL to manipulate data.  Manipulating data is the purpose of a DATA step!  Using conditional logic to manipulate data is not limited to CASE statements in SQL code. You might want to use SQL if you are joining multiple tables in a complex way to create the data that you want to export or if you are using some drag and drop tool in EG to generate your code.       ... View more

Sorry D, but all I see is two steps that create a SAS data set. These do not result in a text file on the OS. That step is still missing. Please run the code I presented and tell me if that gives what you were looking for. The formats I see you using indeed result in proper spacing inside the variable as a result from the CAT() function. It is when writing that variable to an external file where you loose the trailing space unless you use a format in the PUT statement.   If that works consider implementing the logic of your SQL in that same datastep, thus eliminating a step and avoiding passes through your data.   - Jan. ... View more