Le passage de SAS© 9.4 à SAS© Viya™ s'accompagne souvent d'une courbe d'apprentissage concernant la gestion des données en mémoire. Une confusion fréquente survient lors de la transition de PROC SQL vers PROC FEDSQL pour interagir avec des tables chargées dans les bibliothèques CAS (CASLIBs).
Si vous avez déjà rencontré l'erreur "BASE driver, schema name... was not found", cet article vous explique pourquoi cela se produit et comment corriger votre code.
Imaginons que vous travaillez sur un environnement SAS© Viya™. Vous avez défini une CASLIB basée sur un chemin physique (path-based) et vous avez chargé une table en mémoire.
Voici la configuration typique :
| 1 | caslib mycaslib path="/sas/staging/test" datasource=(srctype="path") libref=mycas; |
| 2 |
Chargement des données en mémoire (In-Memory) :
Vous utilisez PROC CASUTIL pour charger une table (par exemple test.sashdat) dans la mémoire du serveur CAS.
| 1 | |
| 2 | PROC CASUTIL incaslib="mycaslib" outcaslib="mycaslib"; |
| 3 | |
| 4 | load casdata="test.sashdat" casout="test" replace; |
| 5 | |
| 6 | RUN; |
| 7 |
Jusqu'ici, tout fonctionne. La table est accessible en mémoire sous le nom mycas.test.
Pour effectuer une agrégation (comme un GROUP BY), vous décidez d'utiliser PROC FEDSQL, qui est l'implémentation standard du SQL pour le moteur CAS.
Vous tentez d'exécuter le code suivant :
| 1 | PROC FEDSQL; |
| 2 | CREATE TABLE mycas.counts AS |
| 3 | select FIELD, count(*) as N |
| 4 | from mycas.test |
| 5 | group BY FIELD; |
| 6 | QUIT; |
C'est ici que le système renvoie l'erreur bloquante :
L'erreur ne provient pas d'un problème de configuration de la bibliothèque ni d'un fichier manquant. Elle est due à la manière dont PROC FEDSQL communique avec le serveur CAS.
Contrairement à une procédure SAS© classique qui s'exécute localement, PROC FEDSQL a besoin de savoir explicitement dans quelle session CAS elle doit opérer pour accéder aux tables en mémoire. Si aucune session n'est référencée, la procédure tente de trouver la table via le moteur local (BASE driver), qui ne connaît pas le schéma "MYCAS" défini sur le serveur distant.
Pour corriger ce problème, vous devez faire deux choses :
Vous assurer qu'une session CAS est active.
Indiquer à PROC FEDSQL d'utiliser cette session via l'option SESSREF.
Voici le code corrigé :
| 1 | /* 1. Démarrer ou référencer une session CAS */ |
| 2 | cas mySession sessopts=(caslib=mycas timeout=3600 locale="en_US" metrics=true); |
| 3 | |
| 4 | /* 2. Appeler PROC FEDSQL en pointant vers cette session */ |
| 5 | PROC FEDSQL sessref=mySession; |
| 6 | CREATE TABLE mycas.counts AS |
| 7 | select FIELD, count(*) as N |
| 8 | from mycas.test |
| 9 | group BY FIELD; |
| 10 | QUIT; |
The codes and examples provided on WeAreCAS.eu are for educational purposes. It is imperative not to blindly copy-paste them into your production environments. The best approach is to understand the logic before applying it. We strongly recommend testing these scripts in a test environment (Sandbox/Dev). WeAreCAS accepts no responsibility for any impact or data loss on your systems.