How should the final code look like? ... View more

You can use the output statement to create a table with the results, then assign a format, and then use proc print or similar to display the results. ... View more

100,000 rows with 200 colums means that the resulting .html page would be at least 100,000*200*30 bytes (including all the HTML tags). That's 600M! Imagine transmitting that to your browser, and displaying it. There's a reason why SAS bucks before that hurdle. If you want to have users access to such big chunks of data, create a stored process that does the subsetting and writes a file for download. The drill through capability in WRS is meant for something that can meaningfully be inspected with eyeballs Mk I. ... View more

You may find it here: TS790 -Diagnosing SAS Enterprise Guide Connectivity Problems ... View more

8591 looks like a workspace server port, not the metadata server port, which is 8561 per default. Do you have access to the metadata repository? Which client are you using? ... View more

If you can get the sort done "on the fly", that is probably the simplest solution. Then the merge just reads sequentially through the tables and writes the target,so it all depends on the sequential I/O throughput of your SAS server. ... View more

Try this: proc sort   data=b /* this is your original oracle data set */     (where = (var1<= date and var2>date and var3>date)   out=dataset1 ; by var1; run; proc sort   data=dataset2 (keep=var1 var2 var3)   out=data2x ; by var1; run; data x; merge   dataset1 (in=a)   data2x ; by var1; if a; run; Compare this method and the SQL method using options fullstimer; Also watch the disks while the jobs are running; you may be surprised by the disk usage(s). I remember when I first came across a piece of code done by a SAS consultant that had > 100 lines. I quickly saw that I could do the same in one create table with ~ 10 lines in PROC SQL, so why bother with all that code? Then I had to wait 5 hours for my SQL to finish, while his code took about 20 minutes to produce the same result. With less than half the disk space. ... View more

You may find an answer here: ... View more

Get in touch with your database admin. That is most probably an error in the setup of your client/instance. ... View more

Once you get to REAL data sets (50 million rows is in this range), you need to take care of your storage infrastructure. a) make it FAST, using high-rpm disks or SSDs for the work area. If you are concerned about failsafes, use RAID1 (simple mirrors). If being failsafe is not a big thing, use striping b) separate your UTILLOC physically from the work/data location, and make sure these disks do nothing else. UTILLOC is where the intermediate file is stored during PROC SORT Then look at this: a) use a combination of proc sort and data steps to do the merge. PROC SQL is a resource hog of the nth order when it comes to large joins. Real life experience here has shown that SQL gets progressively slower when several processes are running, much more than the sort/merge steps. Up to a point where the server becomes unresponsive, which is very rare with an AIX system(!). b) indexes usually don't help (much), because in addition to the data, SAS needs to read the index, causing even more I/O. Indexes are very good if you need to access a small subset of data. c) identify which sort criteria will be needed most, and have your data sets already sorted correctly when you store them. That way users (including yourself) do not need to sort and can read the big datasets sequentially. d) when you do a data step merge, you need space for (just) the source files and the target files. With SQL, you also need space for the utiilty file, which will grow to a size equal of all the source files together. During the sorts preceding the merge, you only need extra space for the file being sorted, the temp file will be in UTILLOC ... View more