My application can read a user defined database whose structure is not known until runtime. A separate application allows the user to create the database and saves information in a known configuration database  which comprises the field names and the type of controls to be created on the WinForm top display the data. I'm not sure where to start to create a generic BO (if possible) that can perform the CRUD operations on the 'unknown ' database structure. Can anyone point me in the right direction,

Many thanks for your time

Dear Ian,

   StrataFrame is designed to work within the IDE. However, you can use the native DataAdapter technology to build commands on the fly.  I used VB for no particular reason, and I've assumed your data is stored in SQL Server tables, again just to build an example; the other data alternatives have analogs:

Imports System.Data.SqlClient

Public Class Form1

  Public da As SqlDataAdapter
  Public cn As SqlConnection
  Public cb As SqlCommandBuilder
  Public cs As String = "your connection string here"

  Private Sub Form1_Load( _
   ByVal sender As System.Object, ByVal e As System.EventArgs) _
   Handles MyBase.Load

    cn = New SqlConnection(cs)
    cn.Open()
    da = New SqlDataAdapter("SELECT * FROM Table", cn)
    cb = New SqlCommandBuilder(da)
    da.DeleteCommand = cb.GetDeleteCommand()
    da.UpdateCommand = cb.GetUpdateCommand()
    da.InsertCommand = cb.GetInsertCommand()

  End Sub

End Class

   However, this couples your connection and SQL to the application, which compromises maintainability. But if that's what you need to do, it is possible.

Les

Ian,



It might be possible, but I'm not sure if it's a good idea. The place to start is to look at the designer code of a BO Mapper generated BO. This will give you an idea of what is needed. Many of the public methods within the designer file could be pretty easily modified to just get meta data from a table (like the database name, the table name, list of fields). However, some are going to be hard, like the enum of field names. Some are going to be very hard, like the static lists and property descriptors. I'm not sure what exactly is necessary to get CRUD working (i.e. maybe the enum isn't strictly necessary...don't know) and what exactly is necessary to manage binding.



I didn't look into this real deeply, but I think Les is likely suggesting a better path of just using native ADO.NET with native .NET binding functionality in a situation like this. I'll be interested to hear what you discover and decide to use.

Hi Guys,

Thank-you both for responding to my query. I would agree that Les's solution does seem to be more straight forward but limited to SQL Server, but I'm sure it possible to extend this. I did look at the code generated by the BOM and wondered if it were possible to write a generic version, but it's only a fledgeling thought at the moment. I'm still considering my options.

Let us know if you still need a bit more direction. Thanks for all of the participation out here guys.