Ed,

It appears to me that your Display Format for the object Duedate in the report 
has been set to a different date format than the date format in your basic 
system.

Check it out by comparing the Display format for Duedate in your report design 
to match the basic setting for your system.

I think this is the reason for nor problem in unloading but an error message on 
the reload.

George



  ----- Original Message ----- 
  From: Ed Rivkin 
  To: RBASE-L Mailing List 
  Sent: Monday, September 14, 2009 1:08 PM
  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



Reply via email to