Sazlo

Aye, thats what I've been doing as a work around. However, Id rather not take that approach if its possible. I find it a tad clunky since those exposed properties contain data that doesnt really apply to the object exposing them. Ive thought along the lines of creating a "helperobject" to contain the necessary information for binding(including child object data) and have the parent create it when needed. I could achieve the same effect and keep the information logically seperated for processing. The helperobject would be a read only snapshot and strictly used for databinding. Perhaps thats a good way to go. Any more input is greatly appreciated. Thanks, Saz

Say i am binding to an ArrayList. The ArrayList contains a group of ObjectA's defined, loosely, as the following: public class ObjectA { private ObjectB objB; public ObjectB ContainedObject { get{return objB;} } } Is it possible to bind to a property of Object B? Ive tried using a binding string of "ContainedObject.SomeProperty" but obviously that doesnt work. Any thoughts? Saz

Absolutely beautiful. Thank you very much *a 1000 times over* for providing such an in depth thought. It will go along ways and is much appreciated. Saz

Hello, This is a bit of a long read, but heres to hoping you read to the end. Perhaps this is an age old discussion, perhaps not. I am a long standing advocate of using stored procs when accessing SQL server. For me, its stored procs for everything, basic CRUD operations, complex data management or manipulation for DTS packages etc. I have a new found friend that disagrees. He is not of the school of thought that stored procs are evil, he just doesn't see the added benefit. Its his opinion that the use of stored procs has the potential to increase information retrieval time and error reporting time. He feels that if you recreate the table structure as a series of tables in a DataSet, with a full setup of DataRelations etc. You can stop trips to the DB for data validation (referencial integrity and such) and thus reduce the time it takes for the application to generate a response in favor or against the request. This leads to the issue of data representation. I am of the belief that the business layer of an application should be exposed as plain old objects (Employee, house, bottle) and be treated as separate entities that handle their own functionality, he is of the type that would prefer a collective approach of sorts. Encapsulate a Datatable into a object and iterate through it as a collection, retrieving information via indexes or Primary keys (into and from the business layer all the way up to presentation), thus having all the information present in a table for updating when ready. He would use one object with 50 employees; I would use 50 employee objects. I hope you can see the argument here: Does the use of stored procs in order to keep client applications (at any abstraction) ignorant to a persistent data structure worth the 5-10millisecond lag time(or less) introduced into the CRUD process? Is there a break even point to which using an in memory representation of a DB out ways the taxing of a server with user requests for stored procs? If given an ability to quickly and easily rewrite the code to create the "in memory" database structure after a change and it just becomes a matter of recompilation and redistribution of applications, does that justify the strong coupling of data and business layers? In a web environment? Thank you kindly for your time and consideration of this matter. Saz