<< Any chance there is a variable in the views whose value could change during the processing (since processing takes some time)? Or changing data? >> You mean like a view definition containing a dotted variable? I don't use that technique. If the view has to change then either a use a temporary view and rebuild it, or reference a temporary table that contains the values I need to use.
The one that failed this morning was PRINT AlertListing1 WHERE ManufactureDate >= 1/1/2008 ORDER BY ManufactureDate, ProjNum, IncidentNum, EmployeeID It's based on a view: SELECT AlertID, BatchNum, PartSN, MachNum, Station,EmployeeID, IncidentNum, + AlertDesc, AlertCause, AlertAction, CreateDate, AlertDispCode, + QAApprovalUser,QAApprovalDate, DefectType, AlertSpec, AlertActual, + ManufactureDate, AlertFault, SGET (ProjPhsVer, 5,1), + (CTXT(IYR4(ManufactureDate)) + '-' + IFLT(IMON(ManufactureDate), 10, '0', NULL) +CTXT(IMON(ManufactureDate))), + (TMON(ManufactureDate) & CTXT(IYR4(ManufactureDate))) + FROM Alert, WorkBtch WHERE Alert.BatchNum = ProjrkBtch.BatchNum The report runs fine most of the time, but occassionally comes up empty. There are no variables used either in the view definition or the print statement. But I'm thinking along the same lines as you -- some subtle R:Base (or external operating system) environmental issue that make R:Base unable to find the rows, producing a blank result set and leading to the second problem I reported — empty reports appear blank instead of generating a 2059. -- Larry
