Les utilisateurs historiques de SAS© 9 cherchent de plus en plus à migrer vers SAS© Viya™ pour exploiter la puissance du moteur CAS (Cloud Analytic Services). Ce moteur distribué et in-memory permet d'accélérer considérablement les processus existants et d'analyser des volumes de données massifs.
Cependant, une étape clé de cette modernisation implique la mise à jour du code PROC SQL vers une procédure native à CAS : PROC FedSQL. Bien que puissante, cette transition peut être déroutante en raison des différences syntaxiques strictes entre les deux langages.
Cet article explore les différences fondamentales et offre un guide pratique pour adapter votre code sans erreur.
1. Comprendre l'architecture : Compute vs CAS
Avant de modifier le code, il est crucial de comprendre où il s'exécute :
SAS© Compute Server : C'est l'équivalent du Workspace Server de SAS© 9. Votre code SAS© 9 existant (et PROC SQL) y fonctionne sans modification.
SAS© Cloud Analytic Services (CAS) : Le nouveau moteur haute performance. Pour qu'une procédure s'exécute ici, les données doivent être chargées en mémoire et le code adapté.
2. PROC SQL vs PROC FedSQL : Les différences majeures
La différence principale réside dans le standard SQL utilisé. Alors que PROC SQL est permissif (extensions SAS©), PROC FedSQL est strict (ANSI-1999).
Tableau 1 : Comparatif des fonctionnalités
| Caractéristique | PROC SQL (SAS© 9 / Compute) | PROC FedSQL (SAS© Viya™ / CAS) |
| Moteur d'exécution | SAS© Compute Server | CAS (Cloud Analytic Services) |
| Standard SQL | ANSI-1992 (Partiel) + Extensions SAS© | ANSI-1999 (Strict) |
| Architecture | Mono-thread (sauf tri/index) | Parallèle, Distribué, In-Memory |
| Types de données | Standard (Char, Numeric) | Étendus (VARCHAR, INT64, DOUBLE, VARBINARY...) |
| Requêtes Fédérées | Non (1 connexion DB par requête) | Oui (Jointures multi-sources possibles) |
| Gestion des erreurs | Arrêt fréquent sur erreur | Option NOERRORSTOP disponible pour continuer |
3. Quelle procédure utiliser et où ?
Une confusion fréquente concerne l'emplacement des données (Bibliothèques locales vs Caslibs). Pour exécuter FedSQL sur CAS, l'option sessref= est obligatoire.
Tableau 2 : Matrice de décision
| Source des données (Input) | Cible des données (Output) | Procédure à utiliser | Note technique |
| Compute (ex: Base SAS©, Work) | Compute | PROC SQL (ou FedSQL sans sessref) | Approche classique SAS© 9. |
| Compute | CAS | PROC SQL | FedSQL sur CAS ne "voit" pas les libnames locaux (Compute). |
| CAS | Compute | PROC SQL | Les données sont téléchargées du serveur CAS vers le client (lent pour gros volumes). |
| CAS | CAS | PROC FedSQL (avec sessref) | La seule méthode pour bénéficier du traitement in-memory distribué. |
4. Guide de Migration : Les pièges à éviter
Voici les différences syntaxiques critiques qui bloquent souvent les développeurs lors de la conversion du code.
Gestion des lignes et pagination
LIMIT au lieu de INOBS : L'option inobs n'existe pas en FedSQL. Utilisez la clause LIMIT à la fin de votre requête.
OFFSET au lieu de MONOTONIC() : La fonction non documentée monotonic() est obsolète. Pour sauter les 5 premières lignes et lire les 5 suivantes, utilisez : LIMIT 5 OFFSET 5.
Rigueur des chaînes de caractères (Le point le plus important)
FedSQL est strict sur l'usage des guillemets :
Guillemets simples ('Texte') : Uniquement pour les chaînes de caractères (valeurs).
Guillemets doubles ("MaVar") : Uniquement pour les noms de colonnes ou de tables (particulièrement s'ils contiennent des espaces ou des caractères spéciaux).
Types de données et Fonctions
Formats : L'option FORMAT= dans le SELECT n'est pas supportée. Utilisez la fonction PUT(col, format.). Attention, cela convertit le résultat en chaîne (VARCHAR).
Typage explicite : Utilisez CAST(variable AS type) ou l'opérateur :: (ex: date::char(10)) pour forcer un type de données.
Fonctions obsolètes : Remplacez RANUNI(seed) par RAND('UNIFORM', min, max).
Syntaxe SQL
Pas de CALCULATED : Vous ne pouvez pas réutiliser le nom d'une colonne calculée dans la même requête (dans un WHERE ou HAVING). Il faut répéter l'expression de calcul.
Opérateurs mathématiques : Les mnémoniques SAS© (EQ, GT, NE) sont interdits. Utilisez les symboles standards (=, >, <>).
Options de Dataset : Les options placées après le nom de la table (ex: table(where=(...))) ne fonctionnent pas. Intégrez tout dans la clause WHERE du SQL.
Pas de ORDER BY en création : Lors d'un CREATE TABLE, l'option ORDER BY est ignorée ou génère une erreur, car les tables CAS distribuées n'ont pas d'ordre intrinsèque.
5. Aide-mémoire de migration (Cheat Sheet)
Ce tableau résume les modifications syntaxiques à effectuer sur votre code.
Tableau 3 : Syntaxe SAS© 9 vs SAS© Viya™
| Action / Concept | Syntaxe SAS© 9 (PROC SQL) | Syntaxe SAS© Viya™ (PROC FedSQL CAS) |
| Limiter les résultats | INOBS=5 | LIMIT 5 |
| Pagination | WHERE MONOTONIC() > 5 | OFFSET 5 |
| Chaînes de caractères | "Texte" ou 'Texte' | 'Texte' (Guillemets simples obligatoires) |
| Noms de variables (spéciaux) | 'Nom Var'n (Name Literal) | "Nom Var" (Guillemets doubles) |
| Variables Macro | "&MaVar" | %TSLIT(&MaVar) |
| Comparaisons | EQ, GT, NE | =, >, <> (Symboles) |
| Options de Dataset | Table(where=(...)) | Clause WHERE SQL standard |
| Formatage | FORMAT=date9. | PUT(col, date9.) (Devient VARCHAR) |
| Typage explicite | N/A (Automatique) | CAST(x as INT64) ou x::INT64 |
| Référence calculée | Mot-clé CALCULATED | Répéter l'expression du calcul |
| Tri à la création | ORDER BY supporté | ORDER BY non supporté dans CREATE TABLE |
La modernisation vers SAS© Viya™ et le moteur CAS offre des gains de performance majeurs. Bien que PROC FedSQL impose une rigueur syntaxique plus forte que le PROC SQL classique, l'adoption de ces standards ANSI garantit un code plus robuste, portable et optimisé pour le traitement distribué. En suivant ces tableaux de conversion, vous éviterez la majorité des erreurs de compilation lors de vos migrations.
