[RBG7-L] - Re: Problem with reports (continued...)

[Javier Valencia]

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: rbg7-l@rbase.com [mailto:[EMAIL PROTECTED]On 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] 781-784-1919 Fax: 781-784-1860 Cell: 339-206-0261 ----- Original Message ----- From: Alastair Burr To: RBG7-L Mailing List 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] ----------------------------------