Ultrawingrid

I never worked with that specific grid, but all the other similar ones that I've used, I always found it easier and actually better to add the extra column in the datasource.
This way, either if it's something that depends on other data on the item or just some static info, it's much easier to manipulate.

If your datasource is a list of objects, just add an extra public property, if it's a DataSet/DataTable, just add an extra column.

if it's a DataSet/DataTable, just add an extra column.

you could define a view in the database which adds the extra column and bind the grid to the view instead of the table. if it is for display only you even may be able to derive the (default) contents of the extra column from other fields.

Sara

@Sara, that's also an option but it would force UI logic into the DB which I think it's a wrong design principle.

If we need to "hack it", it should be in the consumer side.

but it would force UI logic into the DB

'views' in the db are supposed to serve for display purposes. depending on the circumstance whether the info to show in the column is related to the other data or not, it may be less a design fault than to add an empty column to a datasource.

Sara

you are speculating since we don't know which info should be displayed in the additional column and whether it is related to the other data fields or not.

and you argue as a database designer. if you look at the design from the view of application development where the datasource only perhaps only is a means to make the data entered by the user persistent, then the database design is determined (only) from the available data and the design of the form and its controls. if the ui is driven by OOP design, it is a good chance that the db design is OOD as well even if you have to force the objects to relational entities (and most probably there is no mighty db admin who can prevent you from adding columns if you think they are worth to be added).

using a database view allows to use tools to generate the bindings without needing to manipulate the generated exchange modules. therefore, it is much more likely that you can repeat the modeling when new fields or tables were added. this is not possible if you made a customization at the application's side which wasn't preserved by the tools.

Sara

We're deviating from the main issue here, but I can't agree with you on this.
By no means the DB should be ruled by the UI components flaws or limitations.

and most probably there is no mighty db admin who can prevent you from adding columns if you think they are worth to be added

... .which doesn't mean everybody should do whatever they well please.

using a database view allows to use tools to generate the bindings without needing to manipulate the generated exchange modules

Nornal queries, Linq (EF, Linq2Sql, NHibernate or whatever ORM), Stored procedures and in fact views can all serve the same purpose. There's no point here.

From the author question:

I want to add an unbounded column to Ultrawingrid

Unbounded means no persistence.
I keep my point, makes no sense to change the DB (at any level) to serve this purpose.

yes we go off-topic but i will remind you that you started the discussion by your suggestion ' I always found it easier and actually better to add the extra column in the datasource.' with 'datasource' you probably meant the client side but since we don't know whether the Author used a server db or a simple file-based db, it is pure speculation whether the db design was driven by the application or was made by a learned db designer.

By no means the DB should be ruled by the UI components flaws or limitations.

which flaws? which limitations? what are you talking about? do you know more from another thread? from this thread we only know that the User wants to add an additional column to display some info to a grid which was bound to a datasource. i don't know the UltrawinGrid but most likely the code to exchange data from and to the grid was generated by a wizard where it is sufficient to name a datasource and a db table or db view to create the full interface. if so, a new persistent column in the grid simply would need a new column in the table and you either can create the interface again or add the new column manually to the generated code. for a read-only column or column from a joint table, it is much more convenient to provide an appropriate view rather than to add columns to the grid and fill any additional info manually to those columns. the application would decide which data can be read by view and which data were read directly from tables. the db designer (if not identically with the developer) can't make the decision as they don't know what the data mean. their task is to create a relation db model which best fits to the requirements of the applications that were supposed to use the data. so, in case the additional columns should show related data from related entities or derived from other columns, this of course should be provided by an appropriate db view. if the data to display is not related to the other columns, it indeed would be a flaw. but, since it wouldn't make any sense at all, it is not very likely, that it is the case here.

I keep my point, makes no sense to change the DB (at any level) to serve this purpose.

i always found it a funny requirement that each of the 3 tiers database, application, and gui should have their own designer who in no way would let things happen that - as they know by their own judgement - was the job of any of the other tiers. since i have made all three tasks myself (in most projects), and even included an additional network tier, i never had those reservations and can't really understand why a tool like a database should not serve an additional text column if that is needed by the application or by the gui.

Sara

I always found it easier and actually better to add the extra column in the datasource

The datasource is not the database, is the object that you use to bind the grid to (usually a list of objects or a DataTable).

Well, we're going no where with this :)
I don't agree with you and it's enough explanation why.
I have no clue about what you've been doing, and I certainly have no intention to start a "mine is bigger than yours" kind of discussion, but maybe a bit of pure SOA, with different teams managing each layer, will make you understand why the separation of concerns between architectural layers are so important to me (even when they are not explicit).

Nice talking to you, I like these philosophical discussions :)
Cheers!

Now trying to answer the actual question

I've found that the grid supports adding unbound columns.
You can do that in the InitializeLayout event.
Here's the documentation from Infragistics (which is a bit poor)

A better link is actually THIS ONE that points to another question on EE.

So, just to sum up, to add an unbound column you can:

The best choice depends on what you actually want to do with that column.

Cheers mate!

Thanks