<< 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. >>
Well, my problem is occurring across a variety of reports, some based on fairly simple data structures. And my experience has been that these views are completely reliable — they always return what I'm looking for. If the logic is used in different views and I'm willing to pay a performance penalty, I do move the logic into stored procedures and then call the stored procedures from views. Now that I think about it, however, I believe that whenever I have this problem the report _is_ based on a view of some kind, not directly on a table. That's because virtually every report I create is based on a view, even if it's a relatively simple one that joins to tables or aggregates data. It would be a near-fatal problem for me if I had to give up the use of views in this way. I'm working on this some more. By coincidence, I was just testing my new PrintPDF routine when I saw this very problem happen before my eyes, printing a report from the R> prompt. I got an error 46 $$$ scratch file not found. The scratch file was located in my TEMP directory (correctly determined by R:Base at startup from SCRATCH TMP in the config file). Oddly enough, I continued to get this error even after SET SCRATCH OFF (which should have put the scratch files on the database directory) and even after disconnecting and reconnecting the database. Then, when I did CLEAR ALL VAR, it printed! So, I'm thinking something in my variable environment is causing the problem. -- Larry
