The SAS Output Delivery System and reporting techniques

Error handling

Reply
Contributor
Posts: 58

Error handling

I am getting the following error when running a program:
ERROR: Read Access Violation In Task ( SQL ]
Exception occurred at (65DE42F2)
Task Traceback

How do I debug or figure out what is wrong. I am new to SAS and finding it very frustrating to figure out what went wrong.
SAS Super FREQ
Posts: 8,743

Re: Error handling

Hi:
This is not an ODS or Base Reporting procedure question (PRINT, REPORT, TABULATE). Your best bet for help with this question is Tech Support.

In fact, if you go to http://support.sas.com and enter these search terms in the search box:
Read Access Violation In Task SQL

There are many hits that come up -- the problem is that only you know your particular configuration and the set of code circumstances that led up to the Read Access Violation. Here are the first 3 hits:
http://support.sas.com/kb/14/217.html
http://support.sas.com/kb/15/543.html
http://support.sas.com/kb/7/746.html

To send a question to Tech Support, go to http://support.sas.com/ and in the left-hand navigation pane, click on the link entitled "Submit a Problem".

cynthia
N/A
Posts: 0

Re: Error handling

As Cynthia recommended, this isn't an issue that can be resolved here. It is often caused by memory mismanagement under Windows and there are many, many ways in which you can break a Window.

In some cases, this can cause instability in your SAS session and close the SAS session on you. In some more severe cases it can mean the OS session becomes so unstable that Windows shuts down, or asks you to terminate applications and restart. When either happens, you lose your code changes and the log record of what was happening when the error arose. To limit the impact of these issues, I have 2 strategies.

KEEP THE LOG. When I start a SAS session, I do so with a command line that includes the following statements: " -altlog c:\saswork\session.log -unbuflog". The second statement causes SAS to send its log messages as they arise, rather than wait until there is a "page" of data to write. The first specifies the place to send all the log messages. You will still have your usual log window, but now there is a file copy preserved after your session is closed. Debugging becomes much simpler.

HE SAVES. I regularly save my code as I develop it and before I submit it, then when a silly Windows error kills my SAS session I still have my code saved to that point.

With a full log, and a true copy of the code causing the error, you have a better chance of having some evidence for Tech Support to identify the problem.

Sorry if I am off topic Cynthia, but I think this is a fairly important generic issue.

Kind regards

David
SAS Super FREQ
Posts: 8,743

Re: Error handling

I agree that it's important and I'm glad you posted it. As an employee, however, I do feel the need to stay more on topic than off.

However, you're a customer and an enthusiastic proponent of the software and I always learn good things from your words of wisdom -- so as far as I'm concerned, you don't owe me an apology for being off topic. ;-)

cynthia
Ask a Question
Discussion stats
  • 3 replies
  • 142 views
  • 0 likes
  • 3 in conversation