Hello experts,
we have got an old Progress application with a firm, which was aquired by our company.
App is in an obsolete desig - clasic 4GL/ABL client app logic, ABL windows UI + windows database server version 11.5, about 500 database tables, but no app server, no views defined nor stored procedures created (development of this app was started about 20 years before).
Application covers one of a dificult business process of acquired company, but it is too slow and there is a few employees only, who knows internal principes and can to write programs in 4GL.
App is for company internal use only, but out company is large, i.e., there could will to be about 20 database servers across a whole world (or one common server) and about 10 users on each location in a future.
Progress language programmers from acquired firm has no idea how to create and call the stored procedures nor make other cheap and elegant solution for dramatic performance improvement.
Indexes and others we checked already, is not a main performance problem.
Main problem is, in our point of view, in a communcation between client and server.
There are too much data packets transferred, many tens of thousands for one screen/action.
Are there really no posibility to create stored procedures executed on a server side, called from ABL client programs and to transfers to clientst only results of processing?
Many of yours probably had to resolve same problem, I think.
We know, there are application server, but it is not solution for us.
If any solution is more expensive then relativelly cheap, it will be better to rewrite application to a modern and perspective technologies, conforming to a concern development strategy and software we use.
Than only one main question is: is there any possibility to transfer application logic to a Progress database (OpenEdge RDBMS only) server stored procedures, using 4GL/ABL, Java, SQL, NET or other programing language (or other similar inexpensive solution) and call it from 4GL/ABL client application code?
Thank you very much
Ricsi
(ricsi.molnar@yahoo.com ,CIO)