Larry, have you set the following in the command before printing the reports.
set zero on 
set eqnull on 

Gary



________________________________
From: Lawrence Lustig <[email protected]>
To: RBASE-L Mailing List <[email protected]>
Sent: Monday, January 19, 2009 10:00:49 AM
Subject: [RBASE-L] - Re: Continuing problems with empty reports.


<< 
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

Reply via email to