Hi Dirk,

re: You're not alone. :o)

We have experienced the same thing over the years.

I've used CALL EXECUTE for years when the need arises and it works well with the one exception you found. I too have found that at about 2000+ not only the log can get a little wacky but other behaviors also start misbehaving. Every time I have encountered that, reducing the lines submitted always falls back into the "working perfectly" realm.

The reason I say "about 2000+" is that I have tested this quite a bit and the criteria seems to be more related to a buffer size than an actual line count. I was able to reproduce the incursion of problems by reducing the linecount but increasing the volume of text count, and the inverse of increasing the linecount and reducing the bytecount per line. (and I was able to dramatically increase the number of lines when using shorter line lengths, and vice-verse. i.e. The problem does not seem to stem from a specific

line count but rather a specific volume of overall bytes. With fairly typical average line lengths of coding the line count you will incur goofyness is usually just over the 2,000+ linecount mark.

Hope this is helpful.

Mark Terjeson Investment Business Intelligence Investment Management & Research Russell Investments 253-439-2367

Russell Global Leaders in Multi-Manager Investing

Date: Thu, 13 Aug 2009 11:41:12 -0400 Reply-To: Dirk Van Krunckelsven <dirk.vk@GMAIL.COM> Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU> From: Dirk Van Krunckelsven <dirk.vk@GMAIL.COM> Subject: Re: A question on Call execute </cgi-bin/wa?A2=ind0908b&L=sas-l&D=0&P=42126>

Thanks Roland,

That's what I was suspecting as well... Anyone any clue as to what exactly the limit is?

There's not just the yukky log, there's also an error at some point, which is odd, because it works nicely on the other rows for the dataset I have. It even errors on a row that worked earlier that has the same variable, format combination that is relevant to this little sql thing I am doing here.

Oddly enough, after the error, the log printout of the call execute generated code is back to being "nice".

I seem to be obliged to split my dataset and go through the call execute code a couple of times. It's uggly: retrieving Nobs from the controller and then read in the controler using firstobs and obs, and creating an adjusted equivqlent of _N_'s for counting where I am... but seems to work.

Very strange because earlier, for the same thing I create a humongous proc sql with cases for various things on an even bigger dataset and that works nicely... Well...

Dirk

______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________