>In this specific case cursor is no go.
>Thank you.
>
>>I can not resist, but a variable number of strings - this is what a cursor is for. In special in a language, that is designed for it ...
>>

Hi,
I favour Lutz's reply. A cursor is the one you should use. Sorry but a simple 'is no go' is not clear enouogh, please elaborate.
Stay healthy,
Koen
>>Lutz
>>
>>>The values are not really related. But they are designed to address the issue of different ODBC drivers that the application could possible use (I had a thread about that a few days ago). Here are a couple of examples:
>>>

>>>*-- The name of the property has a table name with columns of type VarChar(Max) 
>>>oApp.VarCharMaxTable1 = "cast(Field1 as Text) as Field1, cast(Field2 as Text) as Field2)"
>>>oApp.VarCharMaxTable2 = "cast(FieldA as Text) as FieldA"
>>>

>>>
>>>As you can see (above) that I can store all these strings into elements of an array or have a separate variable.
>>>Thank you.
>>>
>>>>Depends. If the values are related, like different days of a month, use an array. If not, use properties with proper names.
>>>>
>>>>What kind of data will go into these properties?
>>>>
>>>>>Hi,
>>>>>
>>>>>I need to add some properties (all of type string) to the application class/object. It will probably start with about 10 but may grow to about 70 variables (in time). I can create each as a separate string property or combine them all into an array property.
>>>>>Example:
>>>>>

>>>>>oApp.Property1 
>>>>>oApp.Property2
>>>>>*-- vs
>>>>>oApp.aProperty[1]
>>>>>oApp.aProperty[2]
>>>>>

>>>>>
>>>>>Which approach is a better practice, in terms of memory management at run-time?
>>>>>
>>>>>TIA