From: David Carroll on 4 Mar 2010 12:00 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
|
Pages: 1 Prev: PHREG w/ strata question Next: DDE to Share an Excel File |