Jimmy as I think about this, I really don't see adding dynamic columns as being of any help at all. I did a bit of a mental exercise and the following became glaringly obvious:



- unless the users are developers/dba, managing dynamic adds to a database is going to be hard. You have to consider indexing, valid names, defaults, constraints and any server specific issues, such as row size limit on SQL Server 2000 (8060 bytes) or the related row size performance issues with SQL server 2005. I just see all sort of issues and no solutions for trouble the users could get themselves into. (Image the users adding varchar(8000) comments fields to the 10 fields in a table...booom!)



- Allowing user to change the database will make updating the database on your end even harder. I.e. if you need to add a column to a table for some base functionality, but the user already maxed out the table width, your screwed. You won't be able to use the DDT as it would remove any user customizations. I'm sure there are ways around all of this...but wow, that's a lot of work.



- Assuming you manage the dynamic changes (and I mean really dynamic, were you don't know what they might do), then you would need to make your BOs dynamic enough to get to this data. You'd probably have to use regular .NET binding, as new custom properties wouldn't have a bindable property associated with it.



- As Trent mentioned, managing a UI for this will be...er...fun. You'll have to track all those custom columns, the display names, control types, if they are a list, the list source and some how get that on the screen so the user can see it and use it...wow.



The two examples you mentioned are fairly contained though and Ivan's suggestions seem like they'd work better anyway.

1. Dynamic business rules. It seems to me to be more feasible to build a dynamic rule engine than change the db. The BOs are all wired to process any business logic already, you'd just use a dynamic engine for that process. Imagine allowing the users to specify, for example, what fields are required. You could easily just update the RequiredFields property of the BO at run time, based on a set of fields the user has configured and you stored in a db table (which will have its own BO, with a method to get the fields for that table...that you call from the check business rules event each bo, or better in a base business layer that just passed in the table name).



2. Adding comment fields. I see two ways to do this. The easier way is what Ivan suggested, of simply allowing a set number of fields to have optional comments. They simply turn them on off, perhaps set a name. Store this in a configuration table, your good. You could also have a common "comments" table, that tracked the comment, the table the comment is associated with and the PK for the row. This allows for more flexibility, but makes development more complex and can have some performance issues too.



In any case, I'm just throwing out some thoughts and hope they stimulate your development process a bit!

Though I still don't understand how you would implement this in a sense of producing a UI, you could still come up with a solution for this on the BO/DAL side of things.  It sounds like you want to have an application that your end-users highly customize the forms, data, etc.  In a sense, it sounds as though your end-users need a bit of development experience as well.

We have created an environment for some of our reporting to allow our end-users to create queries and data sources that are not distributed with the software by default.  This allows them to create custom reports and queries without ever having to tallk with us...so we both win.  However, if all of this had to translate into user input and dialogs, well, it would become far more complicated.  Past just creating a grid and teling them to "get after it," you are going to have a difficult time with the UI having to be so flexible as well...at least from my perspective.

So the answer is, yes, with some work you can definitely create this type of environment.  But clearly this is not going to be the norm for most development environments past reporting.  I hope that at least gives you an idea of what you are looking for here.

Hey guys,

 

Once again, thanks for the comments. My needs is easy, I want it to be easy for me and my customer to do the customizations, and I don't wants to keep different set of BO Rules with me.

 

The scenarios is simple, for example Customer A would like to have field Country and Branch to be mandatory, while Customer B would like to have field Branch and Division to be mandatory instead. Furthermore some customer would like to have their own comments on each field and they want it through out 1000+ of fields. This process of customization would be hazardous for me to complete, because I have 100+ of customers, and is nearly impossible for me to maintain different set of BOs.

Thanks

Jimmy,

Just to echo what Edhy and Trent have already said: Yes, you can have your customers purchase the DDT themselves and impliment the package creation and deployment portions within your application. As Edhy already mentioned, this would be akin to having them buy stonefield toolkit and using that to customize their structures in VFP.

However, doing so will not dynamically modify your application to account for these changes. I'm not really aware of any framework or system out there that does that type of thing and, like Trent and Edhy, and having some trouble coming up with a scenario where that level of end-user customization would be necessary (let alone desirable.) 

Could you expand on why your customers need that? Some more controled customization (like the custom fileds Edhy mentioned in quick books) might suffice, without opening up pandora's box quite so much .

Thanks!

Dustin

Jimmy, I don't know if you are aware, but I am a VPM MVP Life, and Visual ProMatrix is the framework I use for my VFP projects.

I am sorry, but still you have not describe in detail your real needs, I gave u a couple of scenarios in my previous message and you did not acknowleage any of them.

The images you attached are from an old version of the VPM Data Builder (not your application) and the VPM Data Builder is not designed for an End User use.  That is a developer tool and when used in a compiled VPM application it will have some limitations imposed by VFP runtimes.

StrataFrame has a tool named Database Developer Toolkit (DDT) which does not really compares with the VPM Data Builder, DDT compares more with Stonefield Database Toolkit in the majority of the functionality.

Like I said before, without you letting us know exactly what you want to do, you will get a somewhat inconclusive answer.

Edhy Rijo

Hey thanks Edhy Rijo and Trent L. Taylor.

I'm are building a business solution whereby some of our customers might want to change certain fields base on their requirements.

I've attached two print screen of our exisiting application which built on-top of VPM (Visual ProMatrix), where having a tools call data manager that able to achieve such goal.

However since this is the case as what Trent said, then I might need to seek for a better solution. Of course it will be great if SF able to so.

Hi Jim,

If you don't mind me asking, what kind of application are you working on that will allow end users to change field types? and why?

I have seen several commercial applications like QuickBooks, MS Outlook and others that will allow the end user to add/modify custom fields, but in fact there is no real adding, those custom fields are pre-created in the database as Varchar fields (at least in the case of QuickBooks) and there are only 15 fields available, for those the end user can change only the field caption and I would only imagine that the QB developers are using some sort of Cast or "of Generic" to properly evaluate and display the fields value based on where they are used.  See the attached image for a QB sample form.

By customize field, if you are referring to their captions, I believe you could use the Multilingual capabilities of SF to allow end user change the caption of those controls or use a similar approach as QuickBooks. 

At any rate we will need you to provide more detail on your intended customization in order to provide better approach with SF.

Edhy Rijo

If someone makes a change to the data structure from a string to an integer...you have problems.  Since your application is expecting a string, once this is changed to an integer your application (as well as the BOs) will be expecting a string and in essence be trying to cast an integer as a string.  If there were any characters other than numbers, then an expection would be thrown.

I am not sure what type of application you are developing, but aside from creating a query tool or report writing engine, I do not see how this would work (but I have been narrow minded more than once in my life...and I am sure that my wife would testify to that for me ).

So in short, if you make a change to a data structure to a data type outside of what the application expects, then yes, your app is going to have some problems.

Sorry, I wasn't quite sure with your reply. Does this mean that, a single user can change their database structure on the fly during the runtime. Will there be any problem towards the application, for example if a user change the existing field type of string into integer? My main concern is that, I do not need to re-program my application in order to support the datatype as given in the example. Are the DDT able to achieve this goal?

Kindly Advise.
Thanks.

If you have a Databae Deployment Toolkit package you can programmatically deploy structures when and how you like.  So in this case, I would recommend that my customers purchase a copy of the DDT just to maniupate their structures, then you can programmatically produce the DDT package and deploy it.  This would be the simplest approach to take advantage of dynamic structures in the field.