Ed,
Are you using the PRINT command in RBG76 to generate the file? If so, this could be where you’re getting into difficulties. Go into your RBG76 report definition and click on File / Print to File Setup. Make sure you select “Fixed Length” as the format. Now, for each band, click on the band and select the controls to print. Note the Save Length box. It would be much, much easier in the long run to replace your print-report-load data process with a direct update of the target table, or if you need an interim step, use a temporary table to hold summarized data then perform your update. Emmitt Dove Manager, Converting Applications Development Evergreen Packaging, Inc. [email protected] (203) 214-5683 m (203) 643-8022 o (203) 643-8086 f [email protected] From: [email protected] [mailto:[email protected]] On Behalf Of Ed Rivkin Sent: Monday, September 14, 2009 2:09 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Strange Update Paul, Wasn't aware that this note had an attachment. Strange.... I unloaded and reloaded the table. Upon reload I got an error, ERROR- Column duedate must be a valid DATE. ( 122) Odd to me because duedate is defined as a date. The other date fields didn't give me an error. In addition when I print my monthly 140 records to disk, the duedate field prints as mm/dd/yyyy It loads without any date error. I tried it from the R> prompt with error messages and echo on Sep 13, 2009 09:31:31 PM, [email protected] wrote: Unload and reload. Make sure to ‘Set error messages on’ and watch for them. It could show you an error that was not detected and at the same time it is good to do any ways. Paul D. Also are you aware that this Email has a hidden attachment? At least it was detected by my system ;( I believe this email reply should be free. I will check. From: [email protected] [mailto:[email protected]] On Behalf Of Ed Rivkin Sent: Sunday, September 13, 2009 9:09 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Strange Update Anne, Thanks for the suggestion. It was certainly behaving like a corrupted table. I ran the DB through R:Scope and it came through clean on both structure and data. Emmitt, good point but it seems odd that a Disc / Copy / Conn would cause what I am seeing. Since putting in a pause for 30 secs after the Conn (did that after posting my question), it is working fine. As I am updating 3 tables in the .rmd, I just thought it easier to keep everything together rather than 3 unloads.... Ed Sep 13, 2009 06:34:30 AM, [email protected] wrote: Try running R:Scope on the database. I did have something similar happen when updating an operations table. Every time a record was updated a 2nd copy of the record would appear. Found the customer table, which is a feeder table, had corrupted. Reloaded the customer table from a backup copy and all has been running fine. -------- Original Message -------- Subject: [RBASE-L] - Strange Update From: Ed Rivkin <[email protected]> Date: Fri, September 11, 2009 11:04 pm To: [email protected] (RBASE-L Mailing List) I am curious if someone has faced a similar situation. The problem revolves around a .rmd file originally written for my application 20 years ago using r:base 4.0. I update a table monthly with 140 entries; one for each account. To do so, I print a report to disk, load it into a table and append the table to my master table which is the current Rent table. In addition all rows for accounts with a zero balance are moved to the Rent History table and deleted from the Rent Table Prior to the print / load / append the DB is disconnected and the DB is copied so I have a recovery point in case something fails. The only changes from 4.0-4.5 - 7.6 are the screen handling messages. After testing the conversion everything seemed to work fine. Running parallel we are having a strange problem. Many of the current Rent records are duplicated, others tripled and quadrupled and some of the history data is finding it's way back into the Rent file. When I commented out the Disconnect / Copy to Disk / Connect everything worked fine again. Am I hitting some sort of DB corruption issue? Should I put a Pause for 30-45 secs after the connect? Or am I totally missing something else. Thanks as always, Ed
