Hi Frank,

>
>Thanks Viv,
>
>I'm open to any advice on a better design. I don't understand why you think it introduces potential problems though, so could you explain that, please? The possible properties will all be defined by me so I will know what is there and what I can use, I've just got into the habit of doing things like this in VFP so that I just need to add any new property to the table and it is magically available for me in the code. I suppose I could just make the properties defined ones on an object and just populate them from thetable when I need to. Is that a better design?


It is not likely you will add settings properties to the data and not need to update your application in some way to use them. For this reason using Dynamic properties may be more effort and more fragile than worth it. In addition if the user needs to set or change these setting values, you would most likely need to provide a way for them to do that. The table approach gives them a way if they can access the table, but most you would probably want a form in the application for them to manage the properties. For all those reasons, being dynamic doesn't really add that much value.

I would recommend either using the built in MM configuration settings or using a single row in a table where you can back it with a business object and keep everything strongly typed. It is pretty easy to add a column to a table even dynamically when you push out upgrades and then add another property in the entity object. All the complexity goes away and gives you an easy way to work with your settings.

If this was a desktop application, I would use the CustomSettings class in MM.
Tim