Answered Compatibility of code Progress 9 to OpenEdge 11

Hi Stefan,

Just to give overview to my case.

Problem: We thought at first that it is Coding Incompatibility, because the old program wrote on V9.1 didn't recognize on OE11.4

Example:

Progress 9.1C Coding: "not functioning on Openedge 11.4"

Code:
FOR EACH incident-report WHERE incident-report.confirm = NO
                            AND DATE(incident-report.field60) <= TODAY NO-LOCK:
    DISPLAY incident-report.hrn.

END.


OpenEdge 11.4 Coding: "Revise Coding"

Code:
FOR EACH incident-report WHERE incident-report.confirm = NO NO-LOCK:
    IF DATE(incident-report.field60) <= TODAY THEN
       DISPLAY incident-report.hrn.

END.

but then some of our co-developer progresstalk.com here told that OE is backward compatibility, then it should be run the old program

Answer: since I'm new here in the company I didn't know the history of their programming, and I notice why only on the date we were having a problem, that's why i started to think, did miss the parameter?

to prove what i thought, i just got 1 set of computer install the OE 11.4 and the last it ask the date format usually i didn't change the "mdy" then i try to change to "dmy". then after installing i try to run the same code come from V9, WOW yes it's run.

Conclusion: it think the old Developer here change the date format upon installing the V9 that's why the coding mismatch on 11.4 and i thinks it's not the Version matter, it the date format matter.

Tips: if you already installed the Progress/Openedge and already being see and cannot be reinstall the Software try the following :

1. change the "startup.pf" under C:\progress\openedge
2. 64Bit OS - HKEY_LOCAL_MACHINE->SOFTWARE->PSC->LANGUAGE-><Progress Version>->"Date Format" <change the format you want>
32Bit OS - HKEY_LOCAL_MACHINE->SOFTWARE->PSC->LANGUAGE-><Progress Version>->"Date Format" <change the format you want>
3. reboot the computer.

I Hope this will help in future.

 

Stefan

Well-Known Member
Thanks for the summary, but I still do not understand why the 'adjusted code' would help - with a 'wrong' date setting you will get error 80 (** The month of a date must be from 1 to 12.) on dates that are past the 12th day. I would expect this error to be thrown by both the FOR EACH and by the IF

I think you need to test with an 'edge case' dates - ie dates that will result in an error 80 (** The month of a date must be from 1 to 12.) when executed - ie 17/12/2014 or 12/17/2014 depending on your flavor.

Code:
block-level on error undo, throw.

session:appl-alert-box = true.
session:system-alert-box = true.

define temp-table tt field cc as char.

create tt. tt.cc = "17/12/2014".

session:date-format = "dmy".

run d1.
run d2.

session:date-format = "mdy".

run d1.
run d2.

procedure d1:

    for each tt where date( tt.cc ) < today:
        message 1 tt.cc.      
       
    end.
   
    catch e as progress.lang.error:
        message 'catch?'.        
    end catch.    
   
end procedure.
   
   
procedure d2:  
   
    for each tt:
        if date( tt.cc ) < today then
            message 2 tt.cc.
    end.

    catch e as progress.lang.error:
        message 'catch?'.        
    end catch.    
   
end procedure.

Interestingly - not wanting to hijack the thread - but I cannot seem to catch error 80?!?
 
Hi Stefan,

The reason I think that i haven't get the error are

1. the date format we use on the V9 was dmy and data inside the field was also on the in dmy format so i think error 80 (** The month of a date must be from 1 to 12.) will the appear since they both on the same format.
2. on the OE11.4 the date format was mdy and upon open the application i include the -d dmy parameter to convert the date.. that's why i didn't get the error.

my only question about that is since they are both on the same format why the program didn't capture the record? since they both run in the parameter by dmy the only different with them was on upon installation of v9 by default the that format was dmy and on the OE11.4 it was mdy
 

Stefan

Well-Known Member
Hi Stefan,

The reason I think that i haven't get the error are

1. the date format we use on the V9 was dmy and data inside the field was also on the in dmy format so i think error 80 (** The month of a date must be from 1 to 12.) will the appear since they both on the same format.
2. on the OE11.4 the date format was mdy and upon open the application i include the -d dmy parameter to convert the date.. that's why i didn't get the error.

my only question about that is since they are both on the same format why the program didn't capture the record? since they both run in the parameter by dmy the only different with them was on upon installation of v9 by default the that format was dmy and on the OE11.4 it was mdy

That is exactly my question. I see no reason for this difference based on what you have given us.

The only possibility that can explain the behavior that you are seeing is the that the 'simple' date function is being evaluated by the database server. This 'optimization' could only be done if date settings on client and server are the same. This would mean that your database server is running with an mdy installation. The 'incorrect' client which also had mdy is then triggering the 'optimization'. When the dmy client performs the query, the mismatch in date setting prevents the 'optimization' and the records are returned to the client for client-side evaluation.

But as far as I know the 'optimization' above does not exist - so still grasping at straws.

To get more insight into what is going on you can enable the client logging setting QryInfo.
 
Top