I need to build a mathematical equation in a .p at run time that is based upon data the user entered in a setup maintenance application. The user inputs might be actual numbers or they might be parameters that inform my logic to go grab a piece of data or peform some operation and substitute the result in place of the parameter. The result of the calculation needs to be stored in the database so it can accessed by other applications.
For example: the user enters the following formula in the data entry application into a text box:
{AccountBalance * .25) * ExchangeRate
Account Balance is a parameter that is defined in another table that I need to resolve to a numerical value. That part is easy. If the value of AccountBalance = 1000 and for simplicity sake assume the ExchangeRate is 1.00 the result of the math statement is 250.
The only way I can think to accomplish this is to create a .p on the fly that contains the math statement I parsed together and then run the .p. Am I on the right track or is there a better way? I could have thousands of records to process with this type of logic so performance is a huge concern.
Thanks.
There is a trick for doing this using dynamic queries. You can find it in the Knowledgebase (I hope, otherwise, someone will have to find it for you).
Thanks. Here is the link to the knowledge base article.
If you are using the Ultra Controls, there is also the UltraCalcManager, which is perhaps a more "correct" way of doing this.
Having said that, I tried using the ultraCalcManager and found it to be a couple of orders of magnitude slower than the trick from the knowledgebase.
Not to mention locking one into a platform and being client focused.
tamhas wrote:
Not to mention locking one into a platform and being client focused.
Indeed. One would expect most mathematical expressions to be resolved on the server, so if there is any chance of your server side code ever running on non-windoze, you would stay away from .NET and always use the ABL while you can.
Not to mention those interesting licensing questions about whether it is even legal to use .NET controls which are not related to the UI.
Yeah.. What they said.
Been messing around with the .NET controls so much I forgot there was such thing as a server.
tamhas schrieb:
Not to mention those interesting licensing questions about whether it is even legal to use .NET controls which are not related to the UI.
Don't panic guys!
Anybody ever noticed that the feature enabling access to .NET is called "GUI for .NET"? There is no GUI on a server - the bridge is only part of prowin32.exe and prowc.exe (the web client). So the product does not give you a chance to (potentially) break the license here - code wouldn't even compile in a character client. Those infamous restrictions in the EULA clearly refer to the "Bride" - and not to any other theoretical access to .NET.
The only way you might access .NET classes on a Windows AppServer/WebSpeed/Character client is ComInterop. That requires to compiling an Active-X enabled .NET Assebly in Visual Studio (or at least the SDK) wrapping an Infragistics Component. The license granted by PSC for using UltraControls does not allow the use in any other IDE than OEA/OES.
But I don't see why you shouldn't be allowed to use any of Infragistics Controls when you licensed them directly form Infragistics to build a ComInterop wrapper and use that in any Progress process running on Windows (or use IGs Active X variants of the objects).
You might be interested in knowing about EQN II - it is an open source symbolic mathematics library. You can find it in the code share area here or nab it from
Just to mention, that previous link, changed to