EXTENT argument is a field in a DB query. Terminates from se

Not sure why it breaks drastically like that, but it's a horrible query. I doubt Progress will be able to adequately allocate an index at compile time so it will result in a table read.

Try

FOR EACH Customer WHERE Customer.JoinDate < TODAY - p[customer.Months]

But this code works on 11.5 version. We recently got our system upgraded to 11.7.2 and then the application bombed on these (not exactly this, but exactly same kind of query) existing queries.

You may have hit a version specific bug. As James said, the queries are bad. When the extent field is of size 2, you should actually be using this FOR EACH

FOR EACH Customer

WHERE Customer.Months = 1 and Customer.JoinDate < TODAY - 10

        or Customer.Months = 2 and Customer.JoinDate < TODAY - 20

no-lock:

MESSAGE Customer.CustName.

END.

And ensure there's an index on Months and JoinDate in that order.

No one doubts it ran fine in previous releases.

At this point the cause is not immediately apparent from the information you've provided.  A crash is not normal and indicates a problem.  

There is a whole lot of information that is missing in your post and I would suggest opening a support ticket for investigation.

Start by providing protrace files that were generated by the crashes.  If you haven't done already you will need to install PDB files into your installation folder in order to produce a readable protrace file.  The article below describes how PDB files are installed and used.

000016346 - What is the purpose of .PDB files?

knowledgebase.progress.com/.../P178951

It looks like the database server is crashing(possible index corruption I'm guessing) which is causing a STOP condition which bounces you out of your application.  I would install the PDB files in both the Client and Server machines then reproduce the problem look in the database server's working directory for the protrace files and provide them with your support ticket.

I think the bug may actually be a feature that a responsible PSC developer decided to sneak in despite the backwards compatibility policy after he discovered people have this kind of 'somewhat inefficient code' in production and decided to help them by forcing them to properly fix it this way.

Joking aside, while it ought to work and a support call is legitimate, it should not be called innocent. Except maybe if the real query has more conditions not shown here that cause it to use an index.

Thanks for all the responses.

Some general information on this error.

1. The application has such query embedded in them. Legacy Code. bombed the moment we moved to OE 11.7.2

2. I agree on the Index front; but functionally, why would it terminate the DB connection.

3. We have PROTRACE enabled in our envts. And guess what NO Protraces generated.

4. DB logs show MEMORY VIOLATION.

5. But while trying to replicate the issue in controlled scenario, we did have data constraints put to ensure no such EXTENT references are missed.

6. As an immediate remedy, what we did was, pulled the where clause

Customer.JoinDate + p[customer.Months] <= TODAY, in to an IF condition outside the DB fetch. It did not throw error.

7. Any other combinations with in the where clause, throws out the error.

Out of interest, I added a JoinDate and a Months field to sports2000 in 64bit Progress 11.7.3.

I populated the data as follows:

FOR EACH customer EXCLUSIVE-LOCK:

   customer.months = RANDOM(1,2).

   customer.joindate = ADD-INTERVAL(TODAY,RANDOM(0,48) * 1,"MONTHS").

END.

The query below functions fine in shared memory connections and client/server. So it either works fine in 11.7.3 or there is more to the story. 

DEF VAR p AS INT EXTENT 2 INIT[10,20].

FOR EACH Customer

WHERE Customer.JoinDate + p[customer.Months] <= TODAY no-lock:

MESSAGE Customer.Name.

END.

hahhahah.....Pains of legacy codes, which comes out to haunt. But keeping the indexing issue aside, this should have worked unless PSC has definitely enforced  this. We have raised a support ticket with PSC.