In the SAS© Viya™ architecture, memory and session management is a key concept. It frequently happens that a user loads data or creates a library (caslib) in one session (let's call it Session A), and then wants to access it from a new session (Session B).
However, a direct attempt to assign the existing library in the new session often fails to show the expected data. Why does this partitioning exist and how can it be bypassed?
The core of the problem lies in the scope of your caslib and the tables it contains. By default, when you create a caslib or load a table into memory without specific configuration, it often has a session scope (session scope).
Session Scope: The data is private. It "belongs" exclusively to the session that created it (Session A). Session B can neither see nor use it, even if you try to redefine the library.
Global Scope: The data is shared. It is accessible to all sessions that have sufficient rights to access the CAS server.
It is not possible to simply "connect" Session B to the private memory space of Session A. To make the data accessible to Session B (and others), you must change the status of your data.
The method is to use the promote action.
Instead of trying to reassign the entire library, you must explicitly promote the specific tables you want to share.
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.