Answered Compatibility of code Progress 9 to OpenEdge 11

[Mark Ezekiel P. Torio]

Good Day to Everyone,

I just want to ask about the subject above because after the conversion process we done on our database and try recompile all source program, we notice that some old codes did not work in openedege 11.4

can anyone could help us about this matter, because if we will change the coding, it will take alot of time and include the fact that the original author of the program is already resign in our company, it was pain for us to look every source file to change the program

i hope that there's a solution for that..

thanks in advance.
Mark

 

[tamhas]

What kind of errors are you getting? In general, the biggest risk is in having used a variable or field name which becomes a reserved keyword in a later version. Occasionally, one runs into something which did compile in an older version, but shouldn't have, and now gets caught. But, by and large, ABL is amazing for its upward compatibility.

 

[Mark Ezekiel P. Torio]

Good Day Sir tamhas,

Actually there's no literal error the problem are the coding not running properly.

Example:

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

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


OpenEdge 11.4 Coding: "Revise Coding"

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

 

[Cringer]

When you say it's not working, what do you mean? The code in the top example is perfectly valid code. It may not be the best code in terms of performance as it has a function in the where clause, but it wouldn't have performed well in 9.1C either.

 

[Mark Ezekiel P. Torio]

Hi Sir Cringer,

when we try to run the above code it capture nothing, but when we try to revise the code like below, it captures the data.

the code run when we still use the 9.1D Studio but after the migration to Openedge 11.4 studio i can't recognize the code.

 

[GregTomkins]

Can you post the index definitions of incident-report?

I second what Tamhas said about compatibility. We have maybe 10,000 .p files and have migrated 6 > 7 > 8 > 9 > 10 and were never compelled to make significant changes to any of them as a result of a Progress upgrade. That said, we haven't dealt with 10 > 11 yet.

 

[Mark Ezekiel P. Torio]

Hi Sir Greg

is this the index definition?

Table: INCIDENT-REPORT

Flags Index Name St Area Cnt Field Name Local
----- ----------------------- ------- --- ---------------------- --------
pu PI_INCIDENT 6 1 + SERIAL-NO No

yes, i have also done on migrating 8>9>10, but in my case here in my company they directly migrated from 9>11, and also I'm new here that's why my knowledge on our application is a little.

we notice that we encounter the problem most of the time in "date" when it is place in a variable or in the field formatted by text.

 

[GregTomkins]

It's not clear to me whether your problem is slowness or a fast result that is incorrectly empty. If it's the latter, my next question would be the definition of FIELD60. I am not aware of any rules around the DATE function changing, but maybe they did, or you have some startup parameter problem that is causing date conversions to work wrong.

You could do this:

FOR EACH incident-report NO-LOCK:
DISP field60 DATE(field60) (DATE(field60 <= TODAY)).
END.

Also for your own experience you could experiment with how DATE reacts to different inputs and formats. There may be some startup parameters that affect this, I'm not sure, but a little fiddling around should make clear whether the DATE conversions in your version/configuration are compatible with however FIELD60 is defined.

Lastly, if that's the entirety of your index definitions, as far as access speed goes, there are only two possible scenarios:

1. INCIDENT-REPORT contains a small number of records, eg. a few thousand, in which case, any FOR EACH will be almost instant;

2. INCIDENT-REPORT contains millions of records, in which case, a FOR EACH on anything other than SERIAL-NO will take prohibitively long.

This would be the same on any version of Progress, Oracle, SQL Server, etc. Without an index, it's like you are trying to find someone in the phone book using the third letter of their first name.

 

[Mark Ezekiel P. Torio]

Hi Sir Greg,

not the slowness or a fast is my concern, my concern there was the capturing of data. as my previous post, the incident-report.field60 was in text format and converted to date format & matching on the Today date single line code, when i run the program no record capture, but if i do the other coding same as sample below i capture the record.

this is the parameter i include on the icon using the -pf

-db hms
-S 8000
-H hms
-N TCP
-T C:\temp
-p Z:\hms\general\main.r
-d dmy


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

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


OpenEdge 11.4 Coding: "Revise Coding"

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

 

[Mark Ezekiel P. Torio]

Please help us thanks.

 

[Cringer]

FOR EACH incident-report NO-LOCK:
DISP field60 DATE(field60) (DATE(field60 <= TODAY)).
END.

Please do something like the above and report back results from your 9.1C and from your 11.4 installs.

 

[TomBascom]

It is probably that your "-d dmy" setting is different.

Putting date data into character fields is just asking for trouble. It's a date. Store it in a date field. When you convert it to a string you are embedding assumptions about the format that can easily change. They may even be different from client to client within your system -- especially if users are in different locations. For instance, someone logging in from Europe will probably use a different date format than someone logging in from the US. Or they could just decide to setup their PC differently.

To modify Cringer's request slightly:

display today format "99/99/9999" date( today ) format "99/99/9999".

for each incident-report no-lock:
  display
    field60 format "x(12)"
    date( field60 ) format "x(12)"
    date( field60 ) <= today
  .
end.

Run this in both your old v9 environment and your new oe10 environment.

 

[Mark Ezekiel P. Torio]

Hi Sir Tom & Cringer,

Please see attached files to give you an idea, the previous developer here modified the startup.pf under the c:\progress\startup.pf and change the -d mdy to -d dmy when i ask the senior here they change that to format the report on report builder because on the normal .pf run on the application didn't capture the date format on the report builder but for the transaction it capture, so they came up on that solution to change the startup.pf inside the c:\progress

Now as your request i did run on v9 & v11 when i try to run the v9 this code display today format "99/99/9999" date( today ) format "99/99/9999". error to me to proceed I commented it and run the program then the result is the attached file, and when i run on the v11 there's no error. See 2 attached file


Thanks alot.

 

[Mark Ezekiel P. Torio]

I ask the Senior developer here, why the date format inserted on the text field, they answered that to avoid additional field that may cause the database to shutdown they use the unuse field it like a recycle. its a burden to me there old way of thinking, I'm new here in the company, when little by little seeing there ways on programming a ways shock, and now the senior developer will resign soon and leave this mess to me.

 

[Mark Ezekiel P. Torio]

or do you think upon installation we missed something?

 

[Cringer]

Now as your request i did run on v9 & v11 when i try to run the v9 this code display today format "99/99/9999" date( today ) format "99/99/9999". error to me to proceed I commented it and run the program then the result is the attached file, and when i run on the v11 there's no error. See 2 attached file

It would be helpful to know what the error was you got.

 

[Mark Ezekiel P. Torio]

Hi all,

I know now the problem upon the installation of progress 9.1c the date format was change to dmy, and when we install the OE11.4 it is mdy,

to prove my instinct i try to install the OE11.4 to another computer with date format of dmy, and boom the code capture the record..

know my question how do i change the default date format of OE11.4 without uninstalling & installing new to change only the date format into dmy because our system is currently running and use by the whole hospital staff, Is there any solution to change that i already try to change the startup.pf under the C:\progress\openedge and also the under the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\PSC\Progress\11.4\Language the date format but still it capturing the mdy format


Thanks

 

[Stefan]

session:date-format = "dmy":u.

 

[Mark Ezekiel P. Torio]

we already did that but still the same

 

[Stefan]

session:date-format and -d do exactly the same thing. Since changing -d did not help - you may have something in your code base that is setting session:date-format based on something.