Clarion Errorcode 89 - Record Changed By Another Station

I recently added a new Oracle table to our dictionary and am currently the only one that has access to it. When I attempt to edit a record I get the Error 89. This used to be fairly common when writing to any SQL database due to the way datetimes were stored. And, I suspect that is the cause of this issue; however, the last time I encountered it was probably 10 years ago and I can not recall what the fix was.

I have tried everything I can think of including hand-coding the form and putting WATCH on specific fields in an attempt to make it go away. Nothing worked… Does anyone remember what the cure for this error is?1

Thanks, in advance

Table:

GRIDDEDUCT           FILE,DRIVER('Oracle',GloOraDriver),OWNER(GloOraOwner),NAME(GloGridDeductName),PRE(GRD),BINDABLE,THREAD
GRIDDEDUCT_PK            KEY(GRD:PROD_LINE,GRD:PROD_STYLE,GRD:Operable,GRD:Surface,GRD:Orientation),NOCASE,PRIMARY
Record                   RECORD,PRE()
PROD_LINE                   STRING(2)
PROD_STYLE                  STRING(2)
Operable                    BYTE
Surface                     BYTE
Orientation                 BYTE
Deduct                      PDECIMAL(9,5)
CreatedBy                   STRING(3)
CreateDt                    STRING(8)
CreateGrp                   GROUP,OVER(CreateDt)
CreatedDate                   DATE
CreatedTime                   TIME
                            END
ModifiedBy                  STRING(3)
ModifyDt                    STRING(8)
ModifyGrp                   GROUP,OVER(ModifyDt)
ModifiedDate                  DATE
ModifiedTime                  TIME
                            END
                         END
                     END    

PrepareProcedure code:
IF LocalRequest = InsertRecord
  LocalResponse = RequestCompleted
  DO PrimeFields
  IF LocalResponse = RequestCancelled
    DO ProcedureReturn
  END
ELSIF LocalRequest = DeleteRecord
  IF StandardWarning(Warn:StandardDelete) = Button:OK
    LOOP
      LocalResponse = RequestCancelled
      SETCURSOR(Cursor:Wait)
      DELETE(GRIDDEDUCT)
      IF ERRORCODE()
        SETCURSOR()
        CASE StandardWarning(Warn:DeleteError)
        OF Button:Yes
          CYCLE
        OF Button:No OROF Button:Cancel
          BREAK
        END
      ELSE
        SETCURSOR()
        LocalResponse = RequestCompleted
      END
      BREAK
    END
  END
  DO ProcedureReturn
ELSE
  SAV::GRDPosition = POSITION(GRIDDEDUCT)
  WATCH(GRIDDEDUCT)
  REGET(GRIDDEDUCT, SAV::GRDPosition)
  SAV::GRD:RECORD = GRD:RECORD
END



Code on OK Button:
CASE LocalRequest
OF InsertRecord
  ADD(GRIDDEDUCT)
  CASE ERRORCODE()
  OF NoError
    LocalResponse = RequestCompleted
    POST(Event:CloseWindow)
  OF DupKeyErr
    IF DUPLICATE(GRD:GRIDDEDUCT_PK)
      IF StandardWarning(Warn:DuplicateKey,'GRD:GRIDDEDUCT_PK')
        SELECT(?GRD:PROD_LINE:Prompt)
        CYCLE
      END
    END
  ELSE
    IF StandardWarning(Warn:InsertError)
      SELECT(?GRD:PROD_LINE:Prompt)
      CYCLE
    END
  END
OF ChangeRecord
  LOOP
    LocalResponse = RequestCancelled
    SETCURSOR(Cursor:Wait)
    RecordChanged = False
    IF (SAV::GRD:Record <> GRD:Record) 
       RecordChanged = True
    END

    IF RecordChanged THEN
      PUT(GRIDDEDUCT)
      Update::Error = ERRORCODE()
    ELSE
      Update::Error = 0
    END
  if errorcode()
    message('Clarion Error: ' & ERRORCODE() & ' - ' & ERROR() & '|'          |
          & ' Oracle Error: ' & FILEERRORCODE() & ' - ' & FILEERROR() & '||' |
          & 'Any key to continue...', 'GRIDDEDUCT ERROR', ICON:Hand)
  end
    SETCURSOR()
    IF Update::Error THEN
      IF Update::Error = 1 THEN
        CASE StandardWarning(Warn:UpdateError)
        OF Button:Yes
          CYCLE
        OF Button:No
          POST(Event:CloseWindow)
          BREAK
        END
      END
      DISPLAY
      SELECT(?GRD:PROD_LINE:Prompt)
    ELSE
      IF RecordChanged 
        LocalResponse = RequestCompleted
      END
      POST(Event:CloseWindow)
    END
    BREAK
  END
END

First quick check for me -
Any VARCHAR table fields defined as a STRING in your Clarion Dct?

1 Like

Yes… Makes sense - trailing 0… I will give it a try - thanks…

Similar topic Changed by Another Station - debug code to track cause

1 Like

Oracle DATE datatypes only go to one second precision, and clarion TIME goes down to 1/100ths of a seconds. So, if on the Oracle side you have it declared as DATE, then the date columns are probably not what is causing the problem. If, OTOH, they are declared as TIMESTAMP on the Oracle side, that might be the source.

1 Like

Prime the “ModifiedDate” and “ModifiedTime” with values earlier in your code.

Well, I tried everyone’s suggestions and none of them worked. However, it is fixed… If you look at my primary key (GRD:PROD_LINE,GRD:PROD_STYLE,GRD:Operable,GRD:Surface,GRD:Orientation), I was allowing the user to edit the GRD:Operable, GRD:Surface, and GRD:Orientation fields. This is verboten. I changed the screen so that those fields are now disable on a change and the issue is gone.

Thanks to everyone who offered suggestions…

I will add my experience. I’ve had a call from a customer (one of 60) having issues on one PC with Error 89 all over. MS SQL is behind this. Funny enough, even though no other PC even had my app open, this PC was having major issues with E89. Craziest was that issues happened only with particular data in some fields (nothing to do with date/time at all).

What was the problem? Regional settings of Windows, more precise - administrative code page under Regional setting. Whole Windows were set to Slovenian but this administrative settings which were set to English. When I’ve set this to Slovenian as well, all errors were gone.

Now, strangely, usually when this regional setting is a problem, my app (GUI!) does not show properly special characters like š,č,ž - in menus, prompts etc…
But in this case all was good.
What gave up the secret was one record not showing proper data with special char in the table.

So it seems app was trying to save typed in chars (in entry control) which were in codepage win-1250, but due to admin regional settings, windows tried to save it differently and a mess came up.

4 Likes

Your solution is probably his fix! :blush:

Anothe possibility is if this is a related record to another table, when his data is queried by the other table, or simplly limited, . . the related table may be kicking it out.

1 Like