The quoted string currently being processed has become more than 262 bytes long.

[sutzig]

Is there something going on with SAS OnDemand today? When running a script on SAS OnDemand for Academics which I've successfully run several times before, I am not getting any results, but am instead presented with a long log file which essential re-states by script prepended with 70 lines that start

 1          OPTIONS NONOTES NOSTIMER NOSOURCE NOSYNTAXCHECK;
 2          TITLE;
 3          FOOTNOTE;
 4          OPTIONS LOCALE=en_US DFLANG=LOCALE;
 5          DATA _NULL_;
 6          RUN;

When I try to run a simple import

FILENAME REFFILE '/home/u50257852/FSS_Dashboard/Import/FHC_OCHIN_Screening_and_Follow_Up.xlsx';

PROC IMPORT DATAFILE=REFFILE
	DBMS=XLSX
	OUT=WORK.EPIC_OCHIN_Import;
	GETNAMES=YES;
RUN;

I'm again presented with a long log which begins: "

 NOTE: The quoted string currently being processed has become more than 262 bytes long.  You might have unbalanced quotation marks.
 1          OPTIONS NONOTES NOSTIMER NOSOURCE NOSYNTAXCHECK;
 2          TITLE;
 3          FOOTNOTE;
 4          OPTIONS LOCALE=en_US DFLANG=LOCALE;
 5          DATA _NULL_;
 592        &GRAPHTERM; ;*';*";*/;RUN;QUIT;
                          _________________
                          49

 If I enter nonsense 

proc sql;
	select * from table; quit;

I get exactly the same response.

[tomrvincent]

SAS has had this bug for years and have never been fixed. Look at 'related topics' for more info.

[sutzig]

Thank, tomrvincent. I did look at the related topics and didn't find anything helpful. Most referred to macros which neither my initial file nor the test files include.

[tomrvincent]

Simply stated, you probably have a quote that isn't ended. Even if you fix it, you have to save your project and restart SAS. I've been complaining about this for at least 10 years and nobody at SAS cares about fixing it. It is VERY irritating.

[sutzig]

It is very irritating. Thank you for your guidance. I didn't find a quote that wasn't closed, but, after restarting, I copied my code into a new file piece-by-piece and tested it along the way.

The only cause I can possibly identify is that I had a series of %web_drop_table statements at the head of the script. Maybe that's what cause SAS to choke with a meaningless error.

[tomrvincent]

No problem. I think SAS keeps that bug to torment SAS newbies...like some sort of sick 'rite of passage' 🙂

[SASKiwi]

In my experience this message is mostly caused by SAS users not following correct SAS syntax. It's pretty difficult for code parsers to gracefully deal with all of the possible ways users get their syntax wrong. Most of the time this note warns correctly - there is an unmatched quote somewhere and you need to fix it. So hardly a bug in my opinion.   

[tomrvincent]

The bug is that you can't continue without exiting and restarting. That's a serious bug.

And nearly every cause is not following correct SAS syntax, so that's not an explanation. Nearly every other error can be corrected and the program rerun...except this one.

[Kurt_Bremser]

The bug is in the user's code. Any sufficiently bad code can bring an interpreting language system out of sync that does not completely reset itself with every submit.

The SAS interfaces (Studio and EG) try their very best to correct such mistakes with the "magic string" sent after each submit, but there are conditions where multiple issues (e.g. an open macro definition, with %mend missing or overridden by unbalanced quotes) cause that not to work as intended, and then you need to reset the session.

[tomrvincent]

No, the bug is how SAS responds to the error....a fatal flaw.

[rickwatts]

For what it's worth, and because it might help someone else Googling this same error, I have a problem with long labels in some generated code. The code runs just fine until the program file is %included. Then I get this error same error. The generated labels are clearly longer than the allowed 256 characters, but SAS seems to deal with it ok by simply truncating the labels, until the file is %included when at some point it just gives up and never finishes executing the data step.

[shenzj1994]

The fact that you keep trying to sugarcoating the issue is actually a perfect reflection or mirror of how SAS company and its tech support deals with problem- Blaming the victims.

If you ever look at other interpreter like Python, you would know that it IS the responsibility for an interpreter to accept whatever code user submitted no matter good or bad. It can respond with error message but should recover when the erroneous code is gone. While for SAS interpreter, it just cannot get itself out from the 'bad code' in this scenario. There is no excuse for such interpreter bug, it is something they should have fixed long time ago.

[mkeintz]

---

@shenzj1994 wrote:

The fact that you keep trying to sugarcoating the issue is actually a perfect reflection or mirror of how SAS company and its tech support deals with problem- Blaming the victims.

I think there is a limit in comparing SAS to Python, because I regard SAS not strictly as a language, but rather as a tool that looks like a language.

Even so, I take no side on the degree of unacceptability this problem represents in the SAS interpreter. 

But my experience with SAS does NOT support the contention that SAS tech support deals with problems by "Blaming the victims".  That is a generalization that would require a far broader range of examples.

[SASKiwi]

All software tools have both strengths and weaknesses. Perhaps there is a case to argue that SAS could do better in trapping invalid syntax. However if you compare pretty much any SQL tool with SAS, SAS does a WAY BETTER job of identifying syntax errors than those do. I can't compare SAS with Python as I've never used it.

[shenzj1994]

Blaming the victims is probably a too strong critic but the fact that such interpreter error was never fixed and this post has no SAS people helping does reflect how SAS deals with its problems. Many people continue to use SAS only because the company they work has legacy SAS datasets, think about how many new grad actually learnt SAS instead of Python or SQL?