Blog

The SAS INCLUDE statement, commonly written as %INCLUDE, is used to bring SAS code from an external file into the current program and execute it as if it had been typed directly in place. It is one of the simplest and most practical tools for organizing large SAS projects, especially when programs share setup code, library assignments, formats, macros, or standard reporting routines.

TLDR: The SAS %INCLUDE statement inserts and runs SAS code stored in another file. It helps make programs more modular, reusable, and easier to maintain. In practice, it is often used for project setup files, shared macro definitions, and repeated data preparation logic. Use clear file paths, enable log visibility when needed, and avoid hiding critical logic in too many nested includes.

What the SAS INCLUDE Statement Does

The basic purpose of %INCLUDE is straightforward: it tells SAS to read another source file and submit the code in that file. The included file may contain complete DATA steps, PROC steps, macro definitions, LIBNAME statements, OPTIONS statements, or any other valid SAS code.

A simple example looks like this:

%include "C:\projects\sales_analysis\setup.sas";

When SAS reaches this line, it opens setup.sas, reads the SAS statements inside it, and executes them. From SAS’s perspective, it is almost as though the contents of setup.sas were copied and pasted into the main program at that exact location.

This is useful because serious SAS programs often become long and repetitive. Instead of placing the same setup logic in every program, you can store that logic once and include it wherever it is needed.

Basic Syntax

The most common syntax is:

%include "file-path";

You can also use a fileref, which is often cleaner and more portable:

filename setup "C:\projects\sales_analysis\setup.sas";

%include setup;

Using a fileref separates the file location from the include logic. This can make programs easier to update when files move or when the same code is run in different environments.

You may also add the SOURCE2 option:

%include "C:\projects\sales_analysis\setup.sas" / source2;

The SOURCE2 option writes the statements from the included file to the SAS log. This is especially helpful during debugging because it shows exactly what code SAS executed from the external file.

Practical Example 1: Including a Project Setup File

A common use case is to create a central setup file for a project. Suppose you have a file named setup.sas containing:

options validvarname=v7 mprint mlogic symbolgen;

libname raw  "C:\projects\sales_analysis\data\raw";
libname out  "C:\projects\sales_analysis\data\output";

%let report_date = 31DEC2025;

Your main program can then begin with:

%include "C:\projects\sales_analysis\setup.sas" / source2;

proc contents data=raw.transactions;
run;

This approach keeps the main program focused on analysis rather than environment configuration. If the location of the raw data changes, you update setup.sas once rather than editing every program in the project.

Practical Example 2: Reusing Macro Definitions

Another frequent use of %INCLUDE is loading macro definitions. For example, assume you have a file named macros.sas containing this macro:

%macro summarize_sales(data=, class=, var=);
    proc means data=&data n mean sum maxdec=2;
        class &class;
        var &var;
    run;
%mend summarize_sales;

You can include the macro file and then call the macro:

%include "C:\projects\sales_analysis\macros.sas" / source2;

%summarize_sales(
    data=raw.transactions,
    class=region,
    var=sales_amount
);

This makes macro libraries easier to manage. Rather than redefining the same macro in many programs, you maintain one authoritative version. This is particularly important in regulated or audited environments, where consistency and traceability matter.

Practical Example 3: Including Repeated Data Preparation Code

Suppose several reports require the same cleaned transaction table. You might create a file called prepare_transactions.sas:

data work.clean_transactions;
    set raw.transactions;
    where transaction_date <= "&report_date"d;

    if missing(sales_amount) then sales_amount = 0;
    sales_month = intnx('month', transaction_date, 0, 'b');
    format sales_month yymmn6.;
run;

Your reporting program can then include it:

%include "C:\projects\sales_analysis\prepare_transactions.sas";

proc report data=work.clean_transactions nowd;
    columns region sales_amount;
    define region / group;
    define sales_amount / analysis sum;
run;

This pattern is effective when the preparation logic is stable and used across multiple deliverables. However, it should be documented carefully so users understand where the dataset came from and what transformations were applied.

Using Relative Paths and Macro Variables

Hard coded paths can become a problem when code moves between machines, servers, or users. A common solution is to define a project root macro variable and build paths from it:

%let project_root = C:\projects\sales_analysis;

%include "&project_root.\programs\setup.sas";
%include "&project_root.\programs\macros.sas";

This is more maintainable than repeating full paths throughout the project. If the project is moved, you usually need to change only project_root.

On UNIX or Linux environments, the same idea applies, but the path format is different:

%let project_root = /users/analytics/sales_analysis;

%include "&project_root./programs/setup.sas";

For production work, confirm the path conventions used by your organization. SAS code that runs in Windows Display Manager may need changes before it runs in SAS Studio, SAS Enterprise Guide, or a scheduled server environment.

Important Benefits

The %INCLUDE statement offers several practical advantages:

• Modularity: Large programs can be divided into smaller, purpose specific files.
• Reusability: Common code can be used across many programs without duplication.
• Maintainability: Updates can be made in one place instead of many.
• Consistency: Standard options, formats, macros, and preparation steps can be applied uniformly.
• Cleaner main programs: The primary script can focus on business logic rather than repeated setup details.

Common Mistakes to Avoid

Although %INCLUDE is simple, it can create confusion if used carelessly. One common mistake is including files without making their contents visible in the log. During development, / source2 is often worth using because it improves transparency.

Another issue is excessive nesting. For example, a main program may include setup.sas, which includes paths.sas, which includes macros.sas. This can work, but too many layers make the execution flow harder to follow. In serious production code, the include structure should be intentional and documented.

A third mistake is treating %INCLUDE like a macro call. It is not the same thing. A macro can accept parameters and generate SAS code dynamically. An include statement simply reads and submits code from another file. If you need parameter driven behavior, a macro may be the better tool. If you need to share static code, %INCLUDE is often appropriate.

Best Practices

For reliable use of the SAS INCLUDE statement, consider the following practices:

1. Use descriptive file names, such as setup.sas, formats.sas, or load_macros.sas.
2. Keep included files focused on one purpose whenever possible.
3. Use SOURCE2 during development so the SAS log clearly shows included code.
4. Avoid unnecessary nesting and document any include chain that is required.
5. Prefer configurable paths using macro variables or site approved directory standards.
6. Validate included code independently before relying on it in production programs.

When to Use INCLUDE and When Not To

Use %INCLUDE when you want to share standard SAS statements, setup routines, macro definitions, or repeatable processing blocks. It is a practical choice for organizing code and reducing duplication.

Do not use it to hide complex business logic that reviewers must understand. If an included file performs critical transformations, its role should be clear from the main program and from documentation. Also consider whether a stored macro, autocall macro library, or a more formal job orchestration method would better suit a large production environment.

Conclusion

The SAS %INCLUDE statement is a dependable, widely used feature for managing external SAS code. It improves structure, reduces repetition, and supports consistent execution across related programs. Used carefully, with clear paths, readable logs, and sensible organization, it can make SAS projects easier to maintain and more reliable. Like many powerful tools, its value depends on discipline: include code to clarify a program, not to obscure it.