Recent content by tamhas

Let me add another vote for the PUGgy events. In particular, both at these events and through any other channels you can find, the key goal is to find a champion at Progress. Finding one will make a night and day difference in the attention you can get. A good route might be to develop a talk...

I'll bet that the vast majority of cases are easily encapsulated, some take a bit of thought (which becomes routine after the first few), and a small number are genuinely difficult ... but that often the difficulty exists in the non-OO implementation as well.

Why not encapsulate the for each in the same object as the temp-table? One of the benefits is that one can change the definition of the temp-table and its access without changing the methods of the object.

I understand the temptation in old ABL code, but if you move to OO, you can encapsulate the temp-table in an object and never have the problem again.

Echoing the horror of others, one really needs to be clear about what one needs and wants at run time versus what one needs and wants at compile time. If all you are doing is displaying a value, then you need nothing more complicated than a run time parameter to pass in the value. Oh, and...

One might also note that with good paid help, a huge amount of your time is likely to be saved ... not to mention the predictability and quality of the result ... not to mention the opportunity for learning.

Rather than wasting your time with ChatGPT, you might consider hiring a consultant who actually knows how to do all this stuff.

And fix your indenting ...

My inclination would be: if last-of (tf-tray) then do: find first hist no-lock where hi-itm = if-item-no no-error. if not available (hist) then disp tf-tray. end.

Have you considered simplifying your life by simply adding enough disk not to have to worry about it? They're cheap these days.

Please start a new thread instead of resurrecting one 10 years old.

If you are going to declare something static, you have to really want it to always be there ... and for it to remain "static", i.e., unchanging.

All of which only emphasizes that the performance issues which motivated this delete process almost certainly can be addressed by proper updating and tuning so that actual deletion will be unnecessary unless there is a business case for it ... which has not been stated.

If you want to archive the records, then you want to move them, not delete them. But, think carefully since moving records to an archive table almost inevitably leads to a query across both tables which can be messy compared to a simple query on one table. BUT! This The problem is because...

You might start by rethinking the delete. What are you hoping to accomplish? Disk space is cheap. Data deleted is data lost.