Sure seems like this little "gotcha" should be adderess by the RBTI bug team, NO? Something so difficult to find should be found bay the system and fixed/reported. My opinion.
Dennis McGrath --- Thompson Technology Consultants <[EMAIL PROTECTED]> wrote: > Hallelujah! > > Alastair you are a life saver! I too was printing the reports to a > file. (PDF) > This "Invalid Date" error was causing me to go absolute nuts! I > could find > nothing wrong in my code, variables or report for that matter and it > would simply > popup this "Invalid Date" error completely at random. > > Following your lead below, I looked at my two reports again, > especially the > right margin. Low and behold I had ONE field that the very edge was > on the > margin line. Not over it, but on it. I relocated the field back to > the left a few > pixels, ran the program and NO ERRORS! I ran it multiple times and > again > received NO ERRORS!. This thing was going to cause big problems and > thanks to you it is now fixed. > > One strange thing however.... the field that was "on the margin" was > a > page number field and had nothing to do with a date. Strange that it > gave an "Invalid date" message. > > Anyway, thanks again and this is a great example of the benefit of > the list. > > Bob Thompson > Thompson Technology Consultants > > > -----Original Message----- > From: Alastair Burr [SMTP:[EMAIL PROTECTED] > Sent: Tuesday, August 19, 2003 12:16 AM > To: RBASE-L Mailing List > Subject: [RBASE-L] - RE: The impossible seems to happen > > I don't suppose this is the cause of your problems but it might be a > "heads > up" for others: > > I have recently - ie: it hasn't happened before - had problems with 2 > or 3 > reports that caused R:Base to burp noisily. > When I first checked the reports I could see nothing wrong but they > are all > reports that I print to a file and have a wide right-hand margin. > When I > scrolled over to the far right - just in case - I found that one, or > more > fields crossed over the margin. Naturally, moving the margin further > to the > right so all fields were inside solved the problem. > > Now, I don't think I'm stupid enough to not move the margin when I > placed > the fields so something changed them. It may well be that something > quite > legitimate does this, or I did something stupid, or there's some > circumstance that might do it - an R:Base crash when the form is not > saved - > whatever. > > Either way, it seems that the margins are important even when > printing to a > file which users may not expect. > > Regards, > Alastair. > > Using latest RBW 6.5++ > > > ----- Original Message ----- > From: "Thompson Technology Consultants" <[EMAIL PROTECTED]> > To: "RBASE-L Mailing List" <[EMAIL PROTECTED]> > Sent: Tuesday, August 19, 2003 1:32 AM > Subject: [RBASE-L] - RE: The impossible seems to happen > > > > I have a similar problem while printing a report that is inside a > cursor > > (pointer). I get a random > > "Invalid date" error. Out of a data set of 30 "loops" it will > appear > > anywhere from the > > 2nd record to the 22 record. No change in data or anything. > Simply run > > the program > > multiple times and it gives the error at different records. > Records that > > run fine without > > error one time will produce the error on another run. The program > does no > > updating, > > simply prints two reports for each of the 30 customers. > > > > This sounds like a related issue, but alas I have found no > solution. In > my > > case, I only > > have one date field- InvoiceDate - and searching it is easy. I > found no > > invalid data. > > Reloads or packs did not help. The report was originally driven > off a > view > > and I > > even changed it to temporary tables, but with no improvement. (No > > improvement on > > the error, but speed was significantly improved!) However I still > get > this > > random error. > > > > Troy's mentioning to go away from a While loop is interesting. Is > there a > > known > > issue with pointers or While loops? This is the third time someone > has > > suggested > > not using a pointer. I ask because I use Declare Cursor statements > quite > > often. > > > > Sorry I cannot assist with an answer, but had a few questions of my > own. > > > > Thank you, > > -Bob Thompson > > > > -----Original Message----- > > From: Michael Moser [SMTP:[EMAIL PROTECTED] > > Sent: Monday, August 18, 2003 10:19 AM > > To: RBASE-L Mailing List > > Subject: [RBASE-L] - RE: The impossible seems to happen > > > > Hi Troy, > > > > I thought it might be a memory issue but it seems to be data. It > will > > happen on the first loop if I restrict the pointer to a record that > causes > > the problem but I can not determine why the same variable condition > with > > data from that record will evaluate as False at one point and True > a few > > lines later ... can memory leak show up on the second pass of a > while > > loop? I will try switching to a go to and let you know ... at this > point > I > > will try anything ... > > > > :-} > > > > Thanks for the tip, > > Michael Moser > > EXAQ Micro Services > > Phone: 916-768-7656 > > Fax: 916-966-8313 > > > > >> This is probably a memory leak issue related to a while loop. > > > > >> Try changing your while loop into an IF statement and a GOTO. > > > > >> Troy > > > > >> -----Original Message----- > > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Michael > > >> Moser > > >> Sent: Monday, August 18, 2003 9:46 AM > > >> To: RBASE-L Mailing List > > >> Subject: [RBASE-L] - The impossible seems to happen > > > > > > >> Hi all, > > > > >> Here is a mystery that I have been beating my head against a > wall > > with. > > >> This code processes about 8,000 records just fine then, with > about > > 2,000 > > >> records to go, goes into a infinite loop where variables have > to have > > the > > >> same value but do not. if I reverse the sort order, the > problem > > happens > > >> after about 300 records. > > > > >> P800, 512MB Ram, Windows XP Pro, R:Base 6.5++ 1.864xRT03. > > > > > > >> Suddenly the second while loop starts evaluating as False, > even > though > === message truncated ===
