SAS Enterprise Guide Datum letzte Änderung im Server-Fenster

[basefan]

Hallo zusammen,

im "alten" SAS Display Manager bzw. dem sas.exe auf dem PC wurde im Explorer-Fenster (ziemlich schmal und links aussen) in der Spalte "Modified" Datum/Uhrzeit der letzten Änderung angezeigt.

Das war bzw. ist hilfreich, wenn man seine Daten aufräumen will, z.B. alle alten Data Sets löschen will.

Im EG gibt es unten links das Fenster "Server", dort werden alle Libraries angezeigt. Wenn ich eine Library aufklappe sehe ich die Data Sets innerhalb der Library, aber ohne die Details (Size, Type, Description, Modified). Im Windows-Explorer kann man die Details mit Ansicht->Details einschalten. Gibt es diese Möglichkeit im SAS-EG auch?

Als Not-Lösung habe ich versucht das Data-Set-Datum über rechte Maustaste -> Properties zu finden, aber in dem Properties-Fenster gibt es im Reiter "General" zwar Type, Description, Server, Library, Indexed und Read Only, aber kein "Modified". Über die Properties komme ich also auch nicht an Datum/Uhrzeit der letzten Änderung.

Kann es wirklich sein, dass diese Grundfunktion im EG fehlt?

Gruß aus Betzdorf

Hans

Wir arbeiten mit dem EG 7.13 (64-bit) bzw. mit SAS 9.4 (TS1M3) auf dem Win-7-Client und SAS 9.4 (TS1M3) auf dem Linux-Server. 

[andreas_lds]

Ja, die Funktion fehlt an der Stelle wirklich.

Interessant ist aber: sobald man ein Dataset geöffnet hat und dann die Eigenschaften öffnet, also nicht über das Server-Fenster, sonder über die Dataset-Ansicht, dann steht dort wann das Dataset erstellt und wann es zuletzt modifiziert wurde.

Spontane Idee: Über sashelp.vtable sollte das Modifikationsdatum ermittelbar sein, dann könne man das Löschen via Code erledigen.

Die gute alte Catalog-Ansicht fehlt im EG leider auch.

[CKothenschulte]

---

andreas_lds schrieb:

Spontane Idee: Über sashelp.vtable sollte das Modifikationsdatum ermittelbar sein, dann könne man das Löschen via Code erledigen.

---

Alternativ über die beliebte Prozedur CONTENTS:

proc contents data=sashelp._all_ out=work.test noprint;
run;

Die Spalten CRDATE und MODATE enthalten dann die entsprechenden Zeitstempel.

[mfab]

Tatsächlich nehme ich für solche Abfragen auch immer "sashelp" bzw. "dictionary".

Interessant finde ich in dem Zusammenhang allerdings, dass auch die Anwendungsroutine "Dateien und Formate löschen ..." zwar eine Spalte "Modifiziert" anbietet, diese allerdings leider nicht befüllt ist. Dies würde die eigentliche Anforderung (Manuelle Prüfung und ggf. Löschen anhand letztem Änderungsdatum) genau erfüllen - wäre denn die Spalte "Modifiziert" befüllt... (eGuide 7.13)

[Dennis_V]

Es gibt auch die Alternative mit der ATTRN-Funktion im Makro zu Arbeiten.

%LET DSID = %SYSFUNC(OPEN(SASHELP.CLASS));
%LET MODTE = %SYSFUNC(ATTRN(&DSID,MODTE),DATETIME.);

%PUT &MODTE.;

 Viele Grüße

Dennis

[Kurt_Bremser]

Ich habe das schon mal als Idee zur Abstimmung vorgelegt:

https://communities.sas.com/t5/SASware-Ballot-Ideas/Activate-Properties-for-Files-and-Folders-in-Ent...

Hat leider nicht viele Befürworter gefunden.

[basefan]

Hallo zusammen,

danke für die Ideen&Anregungen wie man das Problem umschiffen kann.

Mein Problem ist meine Zielgruppe. Für die soll es so enfach wie möglich sein und schnell mal einen Macro schreiben fällt nicht unter "so einfach wie möglich".

@Kurt_Bremser

Was muss ich tun um die Idee zu befürworten? Reicht es der Idee mit dem Button am linken Rabd einen Kudo zugeben?

Gruß aus Betzdorf

Hans

[Kurt_Bremser]

---

basefan schrieb:

@@KurtBremser

Was muss ich tun um die Idee zu befürworten? Reicht es der Idee mit dem Button am linken Rabd einen Kudo zugeben?

---

Ja, mehr kann man da nicht tun. Mein Vorschlag ist zwar schon einige Monate her, aber vielleicht hilft die plötzliche "Zustimmungsaktivität" dem Ganzen auf die Sprünge.

[AndreasMenrath]

Hallo Hans,

also der EG ist halt leider nicht als Tool für das Datenmanagement gedacht.

Wenn deine Zielgruppe wirklich nichts mit SAS Code anfangen kann, gibt es wohl nur noch die Möglichkeit selbst eine Erweiterung für den EG zu programmieren und den Anwendern zur Verfügung zu stellen.

Ein solches Addin hat dann eine eigene Oberfläche und Logik. Der Anwender muss dann nur noch die Oberfläche bedienen.

Der Aufwand für die Programmierung eines Addins ist jedoch nicht zu unterschätzen.

Viele Grüße

Andreas

[mfab]

Vielleicht wäre es auch eine Überlegung wert, den Code für die Nutzer vorzufertigen und für alle zugänglich in den Metadaten abzulegen - ggf. als Stored Process.

Dabei könnte man auch mit Prompts arbeiten (z.B. Anzahl Tage für "liste alle Tabellen älter als &anzahl_tage. Tage auf", etc.).

Alternativ kann auch ein ganzes eGuide-Projekt in den Metadaten hinterlegt werden - auch mit entsprechenden Prompts (Eingabeaufforderungen).

[basefan]

Hallo,

ich muss mich korrigieren. Die Anwender können sehr wohl mit SAS-Code umgehen, aber mit Macro-Programmierung würde man sie (wahrscheinlich) überfordern.

Auch die Variante eine Erweiterung für den EG zu programmieren schließt sich quasi automatisch aus (wegen dem genannten beträchtlichen Aufwand).

Der Vorschlag das Problem mit einem Stored Pocess oder einem eGuide-Projekt, beide ggf. mit Prompts ist bestimmt interessant, aber es erscheint mit mit Kanonen nach Spatzen geschossen, um eine fehlende Funktionalität nachzubilden, die im Vorgänger-Frontend enthalten war.

Aber die Problematik ist eine ganze andere: Der alte SAS Display Manager ist für diese Zielgruppe bei uns 'gesetzt'. Um sie von da weg zu lotsen darf das Ziel-System nicht (wesentlich) schlechter sein, als das abzulösende, also als der SAS Display Manager.

Ein Punkt ist der in diesem Thread angesprochene.

Der nächste Punkt, den ich erst in den letzten Tagen beobachtet habe (davor habe ich praktisch noch nicht mit dem EG gearbeitet) ist, dass der EG langsamer als der Display Manager ist (Display Manager natürlich mit remote submit). Ein kleines Test-Programm bestehend aus 6 data steps und 8 proc prints braucht mit dem Display Manager 26 Sekunden, während der EG 42 Sekunden benötigt. Die Daten leigen für beide auf dem gleichem (Linux-) Server.

Aber das gehört eigentlich nicht in diesen Thread. Zumal ich mit dem EG noch weiteres Problem habe: Bei einem einfachen proc print, der 3 Observations drucken soll kommt nach ewiger Wartezeit die Meldung 'The results are large (116.274.692 bytes) and could take a long time and a large amount of system resources to add to the project.'. Scheinbar hat der EG ein Problem mit den vielen Variablen. Es sind in diesem Beispiel 156. Der Display Manager hat damit überhaupt kein Problem und liefert die Antwort im Null-Komma-Nix.

Gruß aus Betzdorf

Hans

P.S.: Ist das communities.sas.com nur für mich so extrem langsam oder ist das ein allgemeines Problem. Jeder Wechsel von einer Seite zu einer anderen dauert mehrere Minuten!

[Kurt_Bremser]

Die meiste Verzögerung im EG entsteht immer beim Anzeigen von Ergebnissen. Die Durchführung der Codes ist gleich schnell.

Bei mir ist auch die communities extrem langsam, aber nur auf dem Firmen-Desktop. Auf dem Tablet via meinem Telefon ist alles normal. Möglicherweise ein Problem mit den Proxies.

[mfab]

Hallo Hans,

ich verstehe den Hintergrund. Es ist immer etwas schwierig neue Tools einzuführen, wenn gewohnte Abläufe dafür verändert werden müssen.

Da ich kaum mit dem Display Manager würde ich jetzt keinen Vergleich wagen.

Allerdings würde ich es mal so ausdrücken, dass man beim Display Manager eine direkte SAS-Session hat, während der eGuide zwar natürlich auch mit einer SAS-Session arbeitet, jedoch das ganze noch etwas netter verpackt und verschiedene Hilfsmittel bietet. Das fängt ja schon damit an, dass das Log entsprechend gestaltet wird. Man bekommt eine Log-Zusammenfassung und kann aus dieser direkt in die entsprechende Stelle springen. Man kann Abläufe grafisch zusammenklicken, Projekte erstellen, ganze Projekte durchsuchen, Ergebnisse nach Excel senden etc. Grundsätzlich also ein deutlich mächtigeres Tool als der DM, dafür braucht der EG vielleicht an der einen oder anderen Stelle auch manchmal ein paar Sekunden länger.

Was die Ergebnisse angeht, so kann man in den Optionen auch einstellen, dass z.B. direkt ein HTML oder PDF erzeugt wird, wenn man dies denn benötigt. Auch die Warnung bei großen Ergebnissen kann man dort anpassen, aber ich denke, das hat schon auch seine Berechtigung, dass da ein Hinweis kommt. Die Warnung sagt ja nichts anderes, als "Achtung, hier werden jetzt ein paar hundert MB übertragen und müssen anschließend auch angezeigt werden".

Im eGuide führe ich praktisch nie ein PROC PRINT aus, weil ich die Tabelle immer per Doppelklick öffnen kann. Oder das Ergebnis, z.B. eines Data-Steps wird direkt als Tabelle angezeigt. Diese Tabellenansicht war für mich schon immer praktischer und schneller als eine PROC PRINT Ausgabe zu betrachten, da man auch mit den Pfeiltasten navigieren kann.

Bei der Ansicht der Tabelle werden auch immer nur Teile der Tabelle an den eGuide übertragen wodurch nicht von vorneherein die gesamte Tabelle, bzw. das Ergebnis des PROC PRINT übertragen werden muss.

Ganz deutlich wird das z.B. auch bei einem PROC SQL; SELECT ... bei einer großen Tabelle hat man auch hier das Problem, dass das gesamte Ergebnis übertragen werden muss.

Wir führen hier bei uns daher ausschließlich PROC SQL; CREATE TABLE work.x AS SELECT ... aus. Somit wird eine Tabelle erzeugt, die wiederum nicht komplett an den eGuide (Client) übertragen werden muss. Schlau wäre an der Stelle wahrscheinlich auch das Erstellen einer View, aber da wir keine Performanceprobleme haben und meist mit der Tabelle weiterarbeiten nehmen wir oft das Create-Statement.

Ich denke, da sind einfach ein paar Anpassungen in der Arbeitsweise angebracht und ehrlich gesagt glaube ich, dass die Arbeit mit dem eGuide durchaus (mehr) Spaß macht und viele sinnvolle Features bietet 😉

Das mit dem direkten Anzeigen von Tabelleneigenschaften mag jetzt etwas sein, wo der EG wirklich nicht glänzt, bzw. was der DM besser macht... ich hoffe, Ihr findet aber noch viele Punkte, die Ihr braucht und die der EG wirklich gut macht.

Beste Grüße

Michael

[basefan]

Hallo zusammen,

@Kurt_Bremser

Das kann ich nicht bestätigen, Im Log ist die Zeit jeweils deutlich verschieden, die Zeit für die Anzeige kommt noch hinzu. In dem Mini-Beispiel ist die Laufzeit, bis ich die Ergebnisse sehe beim EG 133 Sekunden (!!!) statt 26 beim DM.

@mfab

Auch die Warnung bei großen Ergebnissen kann man dort anpassen, aber ich denke, das hat schon auch seine Berechtigung, dass da ein Hinweis kommt. Die Warnung sagt ja nichts anderes, als "Achtung, hier werden jetzt ein paar hundert MB übertragen und müssen anschließend auch angezeigt werden".

Es sind nur 3 Zeilen, wenn ich die nach Excel kopiere und als xlsx speichers sind es nur 16 KB. Ich glaube nicht, dass das einen Hinweis rechtfertigt. Die in der Meldung ausgebene Zahl abstruß hoch ist (116.772.682 bytes), aber für Excel sind es nur 16 KB. Was um alles in der Welt macht der EG mit den paar Byte Rohdaten?

Im eGuide führe ich praktisch nie ein PROC PRINT aus, weil ich die Tabelle immer per Doppelklick öffnen kann. Oder das Ergebnis, z.B. eines Data-Steps wird direkt als Tabelle angezeigt.

Ich wollte nur mal schnell ein paar Datensätze sehen, 3 aus 3 Millionen. Dazu erzeuge ich nicht erst einen Data Set, den ich dann mit Doppel-Klick öffne, das geht mit dem PROC PRINT schneller. Und wegen "nur mal schnell" auch ohne Einschränkung der VAR-Liste, sondern einfach "alles".

Ganz deutlich wird das z.B. auch bei einem PROC SQL; SELECT ... bei einer großen Tabelle hat man auch hier das Problem, dass das gesamte Ergebnis übertragen werden muss.

>>> Ups <<< das ist aber ein Ding, so ein dicker Lapsus sollte nicht sein!

Ansonsten:

Bitte nicht falsch verstehen. Ich hätte den EG bei uns schon lange als einzigen Client eingeführt. Ich frage mich jetzt aber, ob es gut gewesen wäre ...

Gruß aus Betzdorf

Hans

[mfab]

Hallo Hans,

also das kann ich nicht nachvollziehen.

Wenn ich mit PROC PRINT 3 Zeilen aus einer sehr großen Tabelle im EG anzeigen lasse, geht das sehr schnell und es wird nur eine sehr geringe Menge an Daten übertragen.

Mein Punkt ist, dass ich statt z.B.

proc print

  data=in (obs=3);

run;

ein

data work.tmp;

set in (obs=3);

run;

schreibe.

Zugegeben, das mag nicht nötig sein, aber wie gesagt, ich arbeite meist mit den Daten weiter oder mache z.B. im EG ein "senden an Excel".

Bei mir (und das sollte meines Wissens Standard im EG sein) werden die Ergebnisse auch sofort geöffnet. Also muss ich nicht zuerst den DataStep ausführen und dann das Ergebnis öffnen. Ich führe nur den DataStep aus und bekomme das Ergebnis angezeigt. (Oder alternativ kann ich die Ausgangstabelle auch direkt per Doppelklick öffnen und ansehen oder dort z.B. mit einem "Where" arbeiten, um die Tabelle zu filtern.

Dass das SELECT (ohne CREATE) im PROC SQL das komplette Ergebnis übertragen muss ist einfach der Funktionsweise "geschuldet". Man kann im EG einstellen, welche Ergebnisse erzeugt werden sollen. Im Standard wird ein SAS Report erzeugt. Das lässt sich z.B. auch auf PDF umstellen. Das PROC SQL; SELECT... erzeugt also das im EG eingestellte Ergebnis und überträgt dies anschließend auf das System, wo der EG läuft, damit es angezeigt werden kann.

Das ist meines Erachtens ein ganz normales Vorgehen, wobei man freilich darüber diskutieren kann, wie groß das Ergebnis jeweils wird. Aus meiner Sicht wird das Ergebnis als SAS Report immer unverhältnismäßig groß im Vergleich zu den anderen Varianten. Dafür wird es eben direkt im EG angezeigt, wohingegen z.B. für PDF ein separates Tool benötigt wird.

Nochmal: ich denke, es ist einfach eine Frage der Vorgehensweise. Mir ist ein PROC PRINT viel zu unpraktisch, da ich im Ergebnis z.B. nicht mit den Pfeiltasten navigieren und auch keine Zellinhalte kopieren kann.

Wahrscheinlich gibt es auch Verfechter des PROC PRINT, sicherlich auch zurecht, je nach Einsatzzweck. Mein Punkt ist, dass jedes Tool eine gewisse Vorgehensweise begünstigt, das habe ich versucht darzustellen.

Vielleicht kommt Euch das SAS Studio eher entgegen?

Beste Grüße

Michael