From: David Carroll on
Last week we started getting an error with a SAS program which had been
working fine for many months. The code of that program is unchanged as is
the format of the database table it is reading. The only thing that has
changed (that I'm aware of) is that the number of rows in that table
continues to grow (it is now about 66,000.)
I am including a bit of the SAS log when we got this error. Does anyone
know what might explain this error? Would there be some option which
might avoid it? As a work-around, instead of the PROC SQL which pulls the
entire table (and now gets the error), I used two PROC SQLs each with a
subsetting WHERE to pull about half the records each time. (These two
PROC SQLs run fine - no errors.) I then use a data step to put the two
pieces together.
Thanks in advance for any help,
David Carroll

Here's the log snippet:

683 /* set up libname to link to prod synopsis with odbc */
684
685 libname a1 odbc DBMAX_TEXT=6000 dsn=remedy_prod uid=XXXXXX
pwd=XXXXXXX USE_ODBC_CL=YES;

NOTE: Libref A1 was successfully assigned as follows:
Engine: ODBC
Physical Name: remedy_prod
686
687 /* set up file hook and write work dataset out to permanent SAS
dataset */
688
689 libname synop "\\Client\C$\";
NOTE: Libref SYNOP was successfully assigned as follows:
Engine: V9
Physical Name: \\Client\C$
690
691 /* Set up work dataset from Synopsis Trans. History table */
692
693 proc sql;
694 create table Synopsis_TransHist as
695 (SELECT *
696 FROM a1.FHPR_PR_TransHistory a
697 )
698 order by a.Review_ID;
ERROR: Read Access Violation In Task [ SQL )
Exception occurred at (067733B4)
Task Traceback
Address Frame (DBGHELP API Version 4.0 rev 5)
067733B4 06A1E134 arodbc45:SQLGetFunctions+0x396A
0678837D 06A1E1E0 arodbc45:SQLGetData+0x149F
06786E76 06A1E240 arodbc45:SQLFetch+0xAAC
06483FF2 0000012C ODBC32:SQLFetch+0x15F