I tend to use another break to do the report sorts within the last break. My memory is extremely efficient, it empties itself in minutes, so I need to keep things simple. I don't use ORDER BY clauses for reports, only WHERE clauses.
--- Javier Valencia <[EMAIL PROTECTED]> wrote: > Also, make sure that the ORDER BY clause in your statement does not conflict > with the breaks in the report; I found that if you want to use and ORDER BY > clause in your statement, it must include first the exact order of the > breaks and then the additional sort. > Javier, > > Javier Valencia, PE > President > Valencia Technology Group, L.L.C. > 14315 S. Twilight Ln, Suite #14 > Olathe, Kansas 66062-4578 > Office (913)829-0888 > Fax (913)649-2904 > Cell (913)915-3137 > ================================================ > Attention: > The information contained in this message and or attachments is intended > only for the person or entity to which it is addressed and may contain > confidential and/or privileged material. Any review, retransmission, > dissemination or other use of, or taking of any action in reliance upon, > this information by persons or entities other than the intended recipient > is prohibited. If you received this in error, please contact the sender and > delete the material from all system and destroy all copies. > ====================================================== > > -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] Behalf Of David M. > Blocker > Sent: Tuesday, February 22, 2005 9:32 AM > To: RBG7-L Mailing List > Subject: [RBG7-L] - Re: Problem with reports (continued...) > > Alastair > > I bet Emmitt is right - he usually is - but just in case, what you're > describing would also be consistent with damaged indexes. > > Backup the database > Do a PACK KEYS on the database > > See if that makes a difference > > David Blocker > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > 781-784-1919 > Fax: 781-784-1860 > Cell: 339-206-0261 > ----- Original Message ----- > From: Alastair Burr <mailto:[EMAIL PROTECTED]> > To: RBG7-L Mailing List <mailto:[email protected]> > Sent: Tuesday, February 22, 2005 6:59 AM > Subject: [RBG7-L] - Problem with reports (continued...) > > Last month I was having problems with a report that I could not get to print > all the data although if I used a where clause to select approximately half > the data I could run the report against each half with no problems. > > I now have another report where the same thing happens. This time the > report, from the same database, runs against a different selection of data > from a different driving view. > > In both cases: > The report runs against a view; > The data is written to a text file; > I have removed all sort definitions from the view; > The report variables do various lookups and concatenations but nothing very > exciting; > There are multiple break points to sort the data in the report; > The failure seems to occur at around 30,000 records; > Browsing all the data directly from the view and sorting that is no problem; > There is plenty of free disk space; > The results looks perfect with only half the data selected; > I am getting no error messages. > > In one case I use an additional sort clause to sort the detail section's > data. > The output files are quite large: one would be around 16mb but the other is > nearer only 8mb. (The "halves" come in at 9.7mb & 5.9mb in one case and > 4.5mb & 3.7mb in the other.) I have other reports that run to close to 7mb. > > R:Base seems to "stop working" rather than "hang". I can see some disk > activity as if data is still being accessed but the output file remains at a > fixed size no matter how much longer I wait (hours, even). I can disconnect > the database, close the R:>, open and/or close the Database Browser but not > do much else and then I do have to kill R:Base. After that the output files > are perfectly readable only missing the last part of the data. > > I am using the latest beta (#80/W98SE) but I think this has been happening > for some time although I have a feeling that earlier versions of the reports > worked months, maybe as much as a year, ago - but I may not have noticed the > problem then. > > Does anybody have any ideas what I need to look for to correct this? Are > there any limits imposed by the report on sort depth? Or row numbers? Or > output file size? > Is there any significance in the failure row count being close to 32,768? > > Thanks in advance for any suggestions, > Regards, > Alastair. > > ---------------------------------- > A D B Burr, > St. Albans, UK. > ---------------------------------- > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > ---------------------------------- > ===== Albert Berry Management Consultant RR2 - 1252 Ponderosa Drive Sparwood BC, V0B 2G2 Canada (250) 425-5806 (250) 425-7259 (708) 575-3952 (fax) [EMAIL PROTECTED]
