SAS VIYA Guide

From SAS 9 to SAS Viya: The Complete Migration Guide from PROC SQL to PROC FedSQL

Simon 25/01/2022 11 vues

Long-time SAS© 9 users are increasingly looking to migrate to SAS© Viya to harness the power of the CAS (Cloud Analytic Services) engine. This distributed and in-memory engine can significantly speed up existing processes and analyze massive data volumes.

However, a key step in this modernization involves updating PROC SQL code to a CAS-native procedure: PROC FedSQL. While powerful, this transition can be confusing due to strict syntactic differences between the two languages.

This article explores the fundamental differences and provides a practical guide to adapting your code without errors.

1. Understanding the Architecture: Compute vs. CAS

Before modifying the code, it's crucial to understand where it runs:

2. PROC SQL vs. PROC FedSQL: The Major Differences

The main difference lies in the SQL standard used. While PROC SQL is permissive (SAS© extensions), PROC FedSQL is strict (ANSI-1999).

Table 1: Feature Comparison

CharacteristicPROC SQL (SAS© 9 / Compute)PROC FedSQL (SAS© Viya / CAS)
Execution EngineSAS© Compute ServerCAS (Cloud Analytic Services)
SQL StandardANSI-1992 (Partial) + SAS© ExtensionsANSI-1999 (Strict)
ArchitectureSingle-threaded (except sort/index)Parallel, Distributed, In-Memory
Data TypesStandard (Char, Numeric)Extended (VARCHAR, INT64, DOUBLE, VARBINARY...)
Federated QueriesNo (1 DB connection per query)Yes (Multi-source joins possible)
Error HandlingFrequent stop on errorNOERRORSTOP option available to continue

3. Which Procedure to Use and Where?

A common confusion concerns the location of data (Local Libraries vs. Caslibs). To run FedSQL on CAS, the sessref= option is mandatory.

Table 2: Decision Matrix

Data Source (Input)Data Target (Output)Procedure to UseTechnical Note
Compute (e.g., Base SAS©, Work)ComputePROC SQL (or FedSQL without sessref)Classic SAS© 9 approach.
ComputeCASPROC SQLFedSQL on CAS cannot "see" local libnames (Compute).
CASComputePROC SQLData is downloaded from the CAS server to the client (slow for large volumes).
CASCASPROC FedSQL (with sessref)The only method to benefit from distributed in-memory processing.
Illustration
Note :
CAS syntax example:
1PROC FEDSQL sessref=masession;
2 create TABLE casuser.resultat {options replace=true} as
3 select * from casuser.SOURCE;
4QUIT;

4. Migration Guide: Pitfalls to Avoid

Here are the critical syntax differences that often block developers when converting code.

Row Management and Pagination

  • LIMIT instead of INOBS: The inobs option does not exist in FedSQL. Use the LIMIT clause at the end of your query.

  • OFFSET instead of MONOTONIC(): The undocumented monotonic() function is obsolete. To skip the first 5 rows and read the next 5, use: LIMIT 5 OFFSET 5.

String Strictness (The Most Important Point)

FedSQL is strict about the use of quotes:

  1. Single quotes ('Text'): Only for character strings (values).

  2. Double quotes ("MyVar"): Only for column or table names (especially if they contain spaces or special characters).

  • Macro Problem: Since single quotes prevent macro resolution ('&MyVar' does not work), use the %TSLIT(&MyVar) macro function. It resolves the variable and adds the necessary single quotes.

Data Types and Functions

  • Formats: The FORMAT= option in the SELECT is not supported. Use the PUT(col, format.) function. Be aware, this converts the result to a string (VARCHAR).

  • Explicit Typing: Use CAST(variable AS type) or the :: operator (e.g., date::char(10)) to force a data type.

  • Obsolete Functions: Replace RANUNI(seed) with RAND('UNIFORM', min, max).

SQL Syntax

  • No CALCULATED: You cannot reuse the name of a calculated column in the same query (in a WHERE or HAVING). You must repeat the calculation expression.

  • Mathematical Operators: SAS© mnemonics (EQ, GT, NE) are forbidden. Use standard symbols (=, >, <>).

  • Dataset Options: Options placed after the table name (e.g., table(where=(...))) do not work. Integrate everything into the SQL WHERE clause.

  • No ORDER BY in creation: During a CREATE TABLE, the ORDER BY option is ignored or generates an error, as distributed CAS tables have no intrinsic order.

5. Migration Cheat Sheet

This table summarizes the syntax changes to be made to your code.

Table 3: SAS© 9 vs. SAS© Viya Syntax

Action / ConceptSAS© 9 Syntax (PROC SQL)SAS© Viya Syntax (PROC FedSQL CAS)
Limit ResultsINOBS=5LIMIT 5
PaginationWHERE MONOTONIC() > 5OFFSET 5
Character Strings"Text" or 'Text''Text' (Single quotes mandatory)
Variable Names (special)'Nom Var'n (Name Literal)"Name Var" (Double quotes)
Macro Variables"&MyVar"%TSLIT(&MyVar)
ComparisonsEQ, GT, NE=, >, <> (Symbols)
Dataset OptionsTable(where=(...))Standard SQL WHERE clause
FormattingFORMAT=date9.PUT(col, date9.) (Becomes VARCHAR)
Explicit TypingN/A (Automatic)CAST(x as INT64) or x::INT64
Calculated ReferenceCALCULATED keywordRepeat the calculation expression
Sort on CreationORDER BY supportedORDER BY not supported in CREATE TABLE
Illustration

Modernization to SAS© Viya and the CAS engine offers major performance gains. Although PROC FedSQL imposes stricter syntactic rigor than the classic PROC SQL, adopting these ANSI standards ensures more robust, portable, and optimized code for distributed processing. By following these conversion tables, you will avoid the majority of compilation errors during your migrations.