Der Umstieg von SAS© 9.4 auf SAS© Viya™ ist oft mit einer Lernkurve verbunden, was die Verwaltung von In-Memory-Daten betrifft. Eine häufige Verwirrung tritt beim Übergang von PROC SQL zu PROC FEDSQL auf, um mit Tabellen zu interagieren, die in CAS-Bibliotheken (CASLIBs) geladen sind.
Wenn Sie jemals auf den Fehler "BASE driver, schema name... was not found" gestoßen sind, erklärt dieser Artikel, warum dies geschieht und wie Sie Ihren Code korrigieren können.
Stellen Sie sich vor, Sie arbeiten in einer SAS© Viya™-Umgebung. Sie haben eine pfadbasierte CASLIB definiert und eine Tabelle in den Speicher geladen.
Hier ist die typische Konfiguration:
| 1 | caslib mycaslib path="/sas/staging/test" datasource=(srctype="path") libref=mycas; |
| 2 |
Laden der Daten in den Speicher (In-Memory):
Sie verwenden PROC CASUTIL, um eine Tabelle (z.B. test.sashdat) in den Speicher des CAS-Servers zu laden.
| 1 | |
| 2 | PROC CASUTIL incaslib="mycaslib" outcaslib="mycaslib"; |
| 3 | |
| 4 | load casdata="test.sashdat" casout="test" replace; |
| 5 | |
| 6 | RUN; |
| 7 |
Bis hierher funktioniert alles. Die Tabelle ist im Speicher unter dem Namen mycas.test zugänglich.
Um eine Aggregation durchzuführen (wie ein GROUP BY), entscheiden Sie sich für die Verwendung von PROC FEDSQL, der Standard-SQL-Implementierung für die CAS-Engine.
Sie versuchen, den folgenden Code auszuführen:
| 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; |
An dieser Stelle gibt das System den blockierenden Fehler zurück:
Der Fehler liegt nicht an einem Konfigurationsproblem der Bibliothek oder einer fehlenden Datei. Er liegt an der Art und Weise, wie PROC FEDSQL mit dem CAS-Server kommuniziert.
Im Gegensatz zu einer klassischen SAS©-Prozedur, die lokal ausgeführt wird, muss PROC FEDSQL explizit wissen, in welcher CAS-Sitzung es arbeiten soll, um auf die In-Memory-Tabellen zuzugreifen. Wenn keine Sitzung referenziert wird, versucht die Prozedur, die Tabelle über die lokale Engine (BASE driver) zu finden, die das auf dem entfernten Server definierte Schema "MYCAS" nicht kennt.
Um dieses Problem zu beheben, müssen Sie zwei Dinge tun:
Sicherstellen, dass eine CAS-Sitzung aktiv ist.
PROC FEDSQL anweisen, diese Sitzung über die Option SESSREF zu verwenden.
Hier ist der korrigierte Code:
| 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; |
Die auf WeAreCAS.eu bereitgestellten Codes und Beispiele dienen Lehrzwecken. Es ist zwingend erforderlich, sie nicht blind in Ihre Produktionsumgebungen zu kopieren. Der beste Ansatz besteht darin, die Logik zu verstehen, bevor sie angewendet wird. Wir empfehlen dringend, diese Skripte in einer Testumgebung (Sandbox/Dev) zu testen. WeAreCAS übernimmt keine Verantwortung für mögliche Auswirkungen oder Datenverluste auf Ihren Systemen.