The business object's strong-typed properties do not have to reflect the data inside of the business object.  You can retrieve any data you like and access it one of two ways.  All business objects have an "Item" property that will retrieve a column specified:

myBo.Item("MyField") Or MyBo("MyField")

You can also access the data table within the BO and access the rows:

MyBO.CurrentDataTable.Rows(0).Item("MyField")

Ben's post is a more "pure" approach - but both options will work depending upon your circumstances.

The BOMapper does not currently support mapping a business object to a stored procedure.  So, to create a strong-typed business object that maps to a stored procedure, you'll need to create a view that has the same structure as the stored procedure (it doesn't have to be deployed with the database, just created for temp purposes) or create a temp DDT profile and create a table in there with the same structure as the stored procedure.  Either of those will give you a source for the mapping information within the BOMapper.  Once the BO is mapped, it doesn't care where the data comes from, so you can create the structure from a separate object.

Ok, If i create a StrataFrame BO and use the FillByStoredProcedure method what do i point the BO to when I'm in the mapper? Because the StoredProcedure is made up of more than one table.



What do you guys think would be the best way to approach this problem. All I want to be able to do is bind the grid to something so that i am able to retrieve column names and setup the layout of the grid at design-time.

There are some changes to the way the BBS works that haven't been published, yet, so if anything doesn't work the way you want it to, be patient, the next release will most likely fix it.

Oh, and if you want to just set the DataSource of the grid to just a plain data table, you can do that as well.  You can create a method on a business object that will call GetDataTable instead of FillDataTable, and return the retrieved table which you can then set as the DataSource of the grid.  Works the same way as using the BBS to bind the business object to the grid.  You can still configure your columns at design-time.

Mike,

You do not attach a grid to a stored procedure, but rather an object that has been populated using a stored procedure.  If you use an SF business object then you will populate using the FillByStoredProcedure method and attach to the grid using the BO itself or the internal data table.  If you are using your SqlHelper methods, then you will need to populate a dataset or a datatable with the results of the query.  You will then bind the ADO.Net results to the grid through the DataSource property...or whatever 3rd party control you are using.

When you create the grid, you can configure the grid's columns at design time.  After you have the grid's columns defined, you can then drop a BusinessBindingSource onto the form and set the BusinessObject property on the BBS to the business object that you will use to call the stored procedure and store the resultset.  Then, set the DataSource on the grid to the BBS you configured.  Lastly, you just need to create a method on the business object to call the stored procedure and populate the business object with the results.

If a column within the results of the stored procedure does not exist on the business object's properties, don't worry.  You can specify the name of a column that doesn't exist on the business object, but exists within the business object's internal data table and it will work just the same.

How do I bind a grid to a stored procedure in Visual Studio 2005? The twist is that I would like to setup the grid at design time. Column headings, sizes, any additional formatting that I would otherwise have to do in code. Do I somehow create a dataset to bind the grid to initially?



P.S. I really appreciate the general .NET forum... its nice to be able to pull on your knowledge of .NET also.



Thanks