Hallo zusammen, mittlerweile habe ich gefunden, dass ich das Problem mit der Meldung 'The results are too large (116.274.692 bytes) and could take a long time and a large amount of system resources to add to the project.' schon einmal hatte. Es war im Aug. 2013. Damals hieß es, das Ausgabe-Format "SAS Report" (die ODS destination "ODS tagsets.sasreport13") wäre der Grund und die Lösung war mehr ein Work-Around, nämlich das Ausgabe-Format "SAS Report" auszuschalten, also Tools->Options->Results->"Result Formats"->"SAS Report" AUS-Schalten und stattdessen z.B. die HTML-Ausgabe zu aktivieren.   Die damalige Lösung hilft auch hier. Mit HTML-Ausgabe und ohne das Ausgabe-Format "SAS Report" klappt der proc print ohne Meldung. Die Laufzeit ist mit real time 5.23 seconds im Vergleich zum Display Manager mit real time 1.96 seconds immer noch nicht so super, aber das hatte ich davor schon berichtet.   Gruß aus Betzdorf Hans   ... View more

Hallo Kurt, bei uns ist es so: EG 7.13 HF5 (7.100.3.5486) (64-bit) auf Win-7 PC, SAS 9.4 TS1M3 auf Suse Linux (64bit), native SAS-Tabelle, ca. 4,3 GB groß, > 3.000.000 Obs, 156 Spalten) Code: data test6;    /* data set has 3 observations and 156 variables */   set dm3_g.a_kopo_G;   if auftnum eq '2100004711'; run; proc print data=dm3_g.a_kopo_G;  /* 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. */   var %varsort( dm3_g.a_kopo_G ); /* 156 variables */   where auftnum eq '2100004711'; run;   Log dazu aus dem EG: 66         data test6;       /* data set has 3 observations and 156 variables */ 67           set dm3_g.a_kopo_G; 68           if auftnum eq '2100004711'; 69         run; NOTE: There were 3072064 observations read from the data set DM3_G.A_KOPO_G. NOTE: The data set WORK.TEST6 has 3 observations and 156 variables. NOTE: Compressing data set WORK.TEST6 increased size by 100.00 percent.       Compressed is 2 pages; un-compressed would require 1 pages. NOTE: DATA statement used (Total process time):       real time           1.15 seconds       cpu time            1.16 seconds       70         71         72         proc print data=dm3_g.a_kopo_G;  /* The reults are large (116.274.692 bytes) and could take a long time and a large amount of system resources to add to the project. */ 73           var %varsort( dm3_g.a_kopo_G ); /* 156 variables */ MPRINT(LEFT):   ABGRU_AP ANLDAT_A ANLDAT_V ANRSCHL ANSPRNUM ANZFPOS ARBEITSTAG ARCHI_AP ARTINUM ARTINUM8 ARTINUME ARTINUMH ARTINUMW ARTINUMZ ARTINUMZ8 AUDMA AUDMA_AK AUFTART AUFTDAT AUFTJJJJ AUFTNUM AUFTPOS AUFTPOSH AUFTWOCH BELQUELL BEL_CD BILDPOS BRSCH BSARK BSTDK BSTNK_AK BSTZD BTR00 BTR01 BTR02 BTR03 BTR04 BTR05 BTR06 BTR07 BTR08 CTLPC_AK DUBLETTE EAN01 EAN02 EANANZ FEIERTAG FIL3NR FLIEF HTN01 HTNANZ INTEXT INTEXTGR2 KAMGEBIE KDARCHI KLASSIFI KONDM KOTX01 KOTX02 KOTX03 KOTX04 KOTX05 KUNDNUM KUNDNUMO KUNDNWE LABOR LAGERJN LAND1 LPRIO MENGE MENGENAFRA MENGE_FPK MMDD_AK MMDD_AP NAFRA_AP NBEJN NBEJN_O NETWR_AP NETWR_FPK NNWRW_AP PLZ PRLI_AK PRLI_AP PRLI_EP PRLI_EP_ZZ PRODH PRODH2 PRODH4 PRODH6 PRODH8 PRODHAPP PRODH_AP PRODH_AP2 PRODH_AP4 PRODH_AP6 PRODH_AP8 PRODUKT PSTYP RV_WP SA_ODER_SO SCORNECJ SCORNECW SDABW SEITE SEX SGE SKENNUNG SORTIK SPARTE SPRAS SPRAS2 STKLIPOS STRJN STRJN_O TAGTYP THEMA TITSCHL VAGEBIET VA_NR VGBLPOS VKAUS_AP VKBUR VKGRP VKORG VRWRB_AP VRWRT_AP VRWRT_FPK VSART_AK VSART_AP VSTEL_AP VTWEG WAERK WAERS WAGRU WAGRU2 WAGRU4 WEBID WERK_AP WE_JN WLDAT ZTERM ZZADH_AK ZZAUH_AK ZZBRS_AK ZZBRS_KD ZZGCI ZZKON_AK ZZKON_KD ZZKWD ZZMON ZZNEUKA ZZNEUKV ZZSCO_AK ZZSTA ZZVTR_AK ZZWI8 74           where auftnum eq '2100004711'; 75         run; NOTE: There were 3 observations read from the data set DM3_G.A_KOPO_G.       WHERE auftnum='2100004711'; NOTE: PROCEDURE PRINT used (Total process time):       real time           2.80 seconds       cpu time            2.81 seconds     Der Log aus dem DM: 370     data test6;                         /* data set has 3 observations and 156 variables */ 371       set dm3_g.a_kopo_G; 372       if auftnum eq '2100004711'; 373     run; NOTE: There were 3072064 observations read from the data set DM3_G.A_KOPO_G. NOTE: The data set WORK.TEST6 has 3 observations and 156 variables. NOTE: Compressing data set WORK.TEST6 increased size by 100.00 percent.       Compressed is 2 pages; un-compressed would require 1 pages. NOTE: DATA statement used (Total process time):       real time           1.22 seconds       cpu time            1.22 seconds 374 375 376     proc print data=dm3_g.a_kopo_G;     /* 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. */ 377       var %varsort( dm3_g.a_kopo_G );   /* 156 variables */ MPRINT(LEFT):   ABGRU_AP ANLDAT_A ANLDAT_V ANRSCHL ANSPRNUM ANZFPOS ARBEITSTAG ARCHI_AP ARTINUM ARTINUM8 ARTINUME ARTINUMH ARTINUMW ARTINUMZ ARTINUMZ8 AUDMA AUDMA_AK AUFTART AUFTDAT AUFTJJJJ AUFTNUM AUFTPOS AUFTPOSH AUFTWOCH BELQUELL BEL_CD BILDPOS BRSCH BSARK BSTDK BSTNK_AK BSTZD BTR00 BTR01 BTR02 BTR03 BTR04 BTR05 BTR06 BTR07 BTR08 CTLPC_AK DUBLETTE EAN01 EAN02 EANANZ FEIERTAG FIL3NR FLIEF HTN01 HTNANZ INTEXT INTEXTGR2 KAMGEBIE KDARCHI KLASSIFI KONDM KOTX01 KOTX02 KOTX03 KOTX04 KOTX05 KUNDNUM KUNDNUMO KUNDNWE LABOR LAGERJN LAND1 LPRIO MENGE MENGENAFRA MENGE_FPK MMDD_AK MMDD_AP NAFRA_AP NBEJN NBEJN_O NETWR_AP NETWR_FPK NNWRW_AP PLZ PRLI_AK PRLI_AP PRLI_EP PRLI_EP_ZZ PRODH PRODH2 PRODH4 PRODH6 PRODH8 PRODHAPP PRODH_AP PRODH_AP2 PRODH_AP4 PRODH_AP6 PRODH_AP8 PRODUKT PSTYP RV_WP SA_ODER_SO SCORNECJ SCORNECW SDABW SEITE SEX SGE SKENNUNG SORTIK SPARTE SPRAS SPRAS2 STKLIPOS STRJN STRJN_O TAGTYP THEMA TITSCHL VAGEBIET VA_NR VGBLPOS VKAUS_AP VKBUR VKGRP VKORG VRWRB_AP VRWRT_AP VRWRT_FPK VSART_AK VSART_AP VSTEL_AP VTWEG WAERK WAERS WAGRU WAGRU2 WAGRU4 WEBID WERK_AP WE_JN WLDAT ZTERM ZZADH_AK ZZAUH_AK ZZBRS_AK ZZBRS_KD ZZGCI ZZKON_AK ZZKON_KD ZZKWD ZZMON ZZNEUKA ZZNEUKV ZZSCO_AK ZZSTA ZZVTR_AK ZZWI8 378       where auftnum eq '2100004711'; 379     run; NOTE: There were 3 observations read from the data set DM3_G.A_KOPO_G.       WHERE auftnum='2100004711'; NOTE: The PROCEDURE PRINT printed page 24. NOTE: PROCEDURE PRINT used (Total process time):       real time           1.96 seconds       cpu time            1.95 seconds     Der Data Step ist beiden gleich langsam (langsam, weil if statt where verwendet wurde), aber der proc print ist im EG deutlich langsamer als im DM. Mittlerweile ist aber klar, woran das liegt, siehe mein voriger Kommentar mit der Aussage von der Hotline. Es liegt an der ineffektiven Realisierung im EG. Der Code im DM wurde von mir natürlich mit rsubmit gestartet, d.h. es werden keine unnötigen Daten unnötig weit durchs Firmen-Netz bewegt.   Gruß aus Betzdorf Hans   P.S.: Die obigen Log-Auszüge mit den Laufzeiten sind von meinen Test von gestern. Eben habe ich den Proc Print erneut getestet. Jetzt hat er sogar "real time 17.45 seconds" benötigt! Zwei Tests mit zwei ähnlich schlechten Ergebnissen! ... View more

Hallo Michael, mein Beispiel war kein proc print data=test(obs=3); sondern er war mit einer where-Bedingung, aber das geht mit dem data step genauso. Die Idee im EG statt dem proc print den data step zu nehmen, dessen Ergebnis sich normalerweise sofort+automatisch öffnet, ist gut. Als EG-Neuling hatte ich an daran gar nicht gedacht. Das Feature 'öffnet sich automatisch' war just seit ein paar tagen deaktiviert, weil ich zu diesem Problem ein Ticket bei der Hotline eröffnet hatte und der Kollege meinte, ich sollte das deaktivieren, ob das die Meldung verhindern würde. Hat es nicht, aber ich hatte es immer noch deaktiviert. Dank Deinem Tipp weiß ich, wie ich es im EG anders als im DM mache.   Das Rätsel, warum der proc print diese unpassende Meldung bringt ist mittlerweile auch gelöst. Lt. SAS-Hotline reagiert der EG bei der where-Bedingung nicht wie man das erwartet (Eingrenzung der Daten ganz unten, ganz nah an der DB), sondern holt alle Daten 'zu sich' und wertet erst dann die where-Bedingung aus. Wenn er so ungeschickt arbeitet, ist die Meldung klar. Aber wer konnte wissen, dass der EG so extrem ungeschickt arbeitet? Übrigens erzeugt der proc print data=test(obs=3); die gleiche Meldung, also ist auch hier die gleiche ungeschickte Arbeitsweise des EG.   Im SAS-Wiki steht zum Where-Statement genau das drin: Die Selektion findet also *vor* dem Einlesen der Daten in den eigentlichen Datenschritt statt und ist besonders bei großen Tabellen sehr effizient. (siehe http://saswiki.org/wiki/WHERE) Was ist nur in die EG-Entwickler gefahren, dass sie so eine ungeschickte Art der Realisierung gewählt haben? Ich bin entsetzt!   Gruß aus Betzdorf Hans ... View more

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 ... View more

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! ... View more

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 ... View more

Hallo zusammen, @Andreas Danke für die Info, aber ich bleibe erst mal bei unserer bisherigen Vorgehensweise. Die erscheint mit Änderungsfreundlicher zu sein.   @Patrick Danke für die Details zum char-Format. Damit ist das 'seltsame' Verhalten geklärt. Dank dem Link bin ich noch auf eine Gemeinheit bei der Verwendung vom char-Format gestoßen: If you use $CHARw. in an INFORMAT or ATTRIB statement within a DATA step to read list input, then by default SAS interprets any blank embedded within data as a field delimiter, including leading blanks. Zum Glück habe ich aus Gewohnheit kein informat verwendet .... !   Viele Grüße Hans ... View more

Hallo Kurt, ich war so mit experimentieren und dem erstellen des zweiten Kommentars beschäftigt, dass ich Deinen Eitrag gar nicht gesehen habe.   Danke für Deine Hilfe. Jetzt klappt es auch im echten Code. Wie so oft gilt: Kaum macht man es richtig, schon funktioniert's.....   Danke noch einmal!   Viele Grüße Hans ... View more

Hallo, ich habe weiter experimentiert und seltsamerweise hilft das informat auch mit dem cards-Befehl nichts:   data aaa; length kundnum $10 anldat_a $ 8 loevm_A $ 1 sperr $ 1 ; length anrede $ 6 ; length name1 name2 $ 15; informat name1 name2 char15.; input kundnum $10. anldat_A $8. loevm_A $1. sperr $1. anrede $6. name1 $15. name2 $15. strasse $18. plz $6. ort $12. ; cards; 004711471019990303xsFirma Name1          Name2          Strasse mit Hnr   PLZ   Ort 004711471119990202  Firma .                             Wilhelmstr. 1     54321 Musterweiler 004711471219990101  Firma Mustername AG  Spezialfabrik  Emil-Meier-Str. 1 12345 Musterort ; run; proc print data=aaa; run;   Viele Grüße und vielen Dank Hans   ... View more

Hallo Michael, danke für die Lösung. Bisher habe ich den informat-Befehl  eher für verzichtbaren Luxus gehalten. Ich habe es gleich ausprobiert und es klappt. Leider klappt es nur in meinem Beispiel! In meinem echten Code bleibt das Feld, dort heitßt es name1, unverändert leer.   Ich vermute es gibt einen Unterschied zwischen cards und dem echten aus einer Datei einlesen. Ich habe meinen echten Code soweit abgespeckt, dass er überschaubar wird, aber der Effekt immer noch auftritt:   filename datei03 "C:\musterdaten.txt"; data test; infile datei03 obs=999999999 LRECL=555 missover pad end=end ; length kundnum $10 anldat_a $ 8 loevm_A $ 1 sperr $ 1 ; length anrede $ 15 titel $ 15; length name1 name2 name3 $ 40; informat name1 name2 name3 char40.; input kundnum $10. anldat_A $8. loevm_A $1. sperr $1. anrede $15. titel $15. name1 $40. name2 $40. name3 $40. strasse $60. plz $10. ort $40. ; output; run; proc print data=test; run;   Die Test-Daten sehen so aus: 004711471019990303xsFirma Name1          Name2          Strasse mit Hnr   PLZ   Ort 004711471119990202  Firma .                             Wilhelmstr. 1     54321 Musterweiler 004711471219990101  Firma Mustername AG  Spezialfabrik  Emil-Meier-Str. 1 12345 Musterort Damit bekomme ich trotz dem informat-Befehl immer noch ein leeres Feld statt den Punkt als Befüllung.   Viele Grüße und vielen Dank Hans   ... View more

Hallo, ... Beitrag von damals gefunden: Nicht gefüllte Zellen mit Proc Freq ausgeben   Gruß Hans ... View more

Hallo Anika, Forum einen Beitrag mit dem Titel "Nicht gefüllte Zellen mit Proc Freq ausgeben". Darin waren drei Lösungen skizziert, die sich aber auf den proc freq bzw. den proc tabulate beziehen. Aber die Lösung lässt sich ggf auf Deine Prozedur übertragen. Die Redscope-Beiträge wurden alle nach CoDe SAS übernommen, rechts unten ist der Link ins Archiv, siehe "Redscope Archive". Dort auch Direkter Zugriff auf alle Beiträge aus den Jahren 2005 - 2014. Viel Erfolg beim Suchen, vielleicht hilft es: Die Lösungen sind vom 17. August 2011 und vom 22. August 2011, beide von Jan Heuer.   Gruß Hans ... View more