Possibility of creating a variable dynamically - Forum - OpenEdge Development - Progress Community

Possibility of creating a variable dynamically

 Forum

Possibility of creating a variable dynamically

  • Hello Guys,

                   wanted to know if it is possible to create a variable at runtime with different data type at different runs ?

         What I'm looking for is -

                                             I need to return a value from a procedure where I would not know the data type of my return value for fixed. it would be character for some, but could be integer or date also. I do have the information of the data type from a DB field mentioned in another parameter, so accrodingly need to throw out the return value for the same data type.

    Now can we have something like -

    create a handle. then create a variable like that field on that handle , like any other dynamic object creation.

    IS IT POSSIBLE ?

    Progress 9.1E

    OE 10.1C

    AIX 5.3

    TIA

    Debayan

  • Hello Debayan,

    ordinary variables don't have handles in the ABL so you can't create them at runtime and return a handle.

    You could:

    • create an object dynamically (DYNAMIC-NEW) and return that as a parameter of Progress.Lang.Object. You'd need a class with a single property for each possible data-type you wanna return. Be aware that in 10.1C the caller will have to delete the returned object as garbage collection is only available in 10.2A.
    • create a temp-table with a single field individually. As your description contains some dependency on database fields, that might make sense. But creating temp-tables at runtime has some overhead - so I wouldn't do that over and over in a loop.
    • have a number of output parameters for each possible data-type

    DEFINE OUTPUT PARAMETER poChar AS CHAR NO-UNDO.

    DEFINE OUTPUT PARAMETER poInt AS INTEGER NO-UNDO.

    DEFINE OUTPUT PARAMETER poDecimal AS DECIMAL NO-UNDO.

    ....

         I guess this will have the least overhead... But it might be ugly to code, as you are expecting something with a handle.

    But with a handle (thinking of the class or tt solution): How is the caller supposed to do something with that returned variable if you don't know the data-type? If you are just outputting the value - and not crossing the appserver boundary - how about returning a generic Character parameter?

  • I'd suggest returning a character, since it's possible to convert just about every data type to a character and back again.

    Another possibility is to have a single-record TT w/all the data types in it, and pass a BUFFER out of the procedure for a self-serve session.

  • timk519 schrieb:

    I'd suggest returning a character, since it's possible to convert just about every data type to a character and back again.

    But be careful, when an AppServer is involved! Client and AppServer do not need to have the same -d and -E settings (or -numsep and -numdec). In that case, the client might have difficulties interpreting and converting back and forth again the value.

    Especially when using the new -useOsLocale parameter in 10.2A it's rather unpredictable to knjow what format the client want's to receive.

  • DYNAMIC-NEW won't be available in 9.1 ... if this were a sufficiently modern version, you could define a class with overloaded method signatures, but that won't fly in 9.1.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • To pass dates, always put them in ISO format to avoid confusion, i.e., 2009-04-14

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • The original post mentioned

    Progress 9.1E

    OE 10.1C

    Maybe a 9.1E DB and 10.1C client? DYNAMIC-NEW would work in that environment. Only guessing!

  • and how about decimal numeric values?

    Seriously - with having a lot of experience with different numeric and date formats in action, I always prefer to pass original datatypes and not "homegrown" string formats.

  • One can also pass INTEGER(date), and then convert it back via DATE(integerval) to avoid locale-specific issues.

  • No question that my preferred solution would be the overloaded method ... but not in 9.1.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • And Decimals? I know, you could always multiply by 10^x and convert to string and back, but how to justify that when passing the original data type is available?

    Need to know the use case of the original poster to discuss more.

  • What about decimals?

    Does this suffice -

    message decimal("1,23") decimal("123") decimal("1,23.45") decimal("123.45").

  • Highly dependent on session settings - and those can be different between client and appserver. Try this

    SESSION:NUMERIC-FORMAT = "EUROPEAN".

    message decimal("1,23") decimal("123") decimal("1,23.45") decimal("123.45").

    SESSION:NUMERIC-FORMAT = "AMERICAN".

    message decimal("1,23") decimal("123") decimal("1,23.45") decimal("123.45").

    Inpredictable when using the -useOsLocale startup parameter in 10.2A...

  • But, isn't SESSION:NUMERIC-FORMAT only a display parameter?  If one passes decimal values as "1234567.89" and converts using DECIMAL, it works the same with American or European format.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • tamhas schrieb:

    But, isn't SESSION:NUMERIC-FORMAT only a display parameter?

    No - like the DATE-FORMAT it influences the result of the STRING, DATE and DECIMAL and INTEGER functions. Everything that converts a date, decimal or integer to string and back.

    Ever wondered why the footer of the .d dump files contain the date and numeric format?