Larry: you mention "I don't use that technique". FWIW, I don't use the view technique that you are using. I've never "trusted" a view definition that has the complicated calculations that you have in yours. I remember the old "out of internal space" errors.... If it was me, I'd turn it into a temp table with an update command to put those calculations in there. You could also put the code in a stored procedure if it's a data definition that is called from multiple places.
Karen > 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 >
