1. You have a SQL Server Database called "MyDatabase" with a single table "tblCustomer" which has 2 columns "CustNo" and CustName". Ran through the SF Business Mapper creating a BO called MyDatabaseBO which generates a DLL for MyDatabaseBO.

  2. You have an Oracle Database called "MyDatabase" with a single table "tblCustomer" which has 2 columns "CustNo" and CustName". Ran through the SF Business Mapper creating a BO called MyDatabaseBO_ORACLE which generates a DLL for MyDatabaseBO_ORACLE.

  3. You generate an SF Windows Forms project similar to the the security sample and add the following to it:

      a. You add an application key field to the app.config called "UseOracleType" and set it's default value to false.

      b. You then generate a SF Maintenance form and drag the tblCustomer BO from the SQL BO (MyDatabaseBO) to the form and get things running against the SQL BO. In this casde most of the clients using the Application are SQL clients.

   4.  When I generate the Windows Application, there is a reference to the MyDatabaseBO DLL and not the MyDatabaseBO_ORACLE DLL.

Now we have a client that wants to use ORACLE and not SQL. For now, lets not address the issue of RBS which must be SQL, but just the database for the data.

My thoughts are then to set the Application Key field in the app.config to "UseOracleType" = true.

The user start the application but when they click on the form to display the Customer Maintenance form, I want to use the MyDatabaseBO_ORACLE DLL in place of the MyDatabaseBO DLL. The naming conventions on all the table names and column names in both DLLs are identical.

Here is the question?

Is there a way when any form loads, to programatically check the app.config "UseOracleType" and if "true" to programmatically change the BO from MyDatabaseBO to MyDatabaseBO_ORACLE. My thought here is that all table names and column names are identical? If you what event for the form would you use.

No, this is not a correct assumption.  I am pretty confident that you and I have had this conversation on a different thread a while back.  But to recap, you would convert an SqlDbCommand into an OracleDbCommand in your BaseBO.  You already know if you are running in an Oracle or SQL Server environment.  There is absolutely no need to write all of your queries, etc. twice as this would be a poor design as open the door for a lot of potential bugs, not to mention testing.

You can override all of the necessary BO commands.  So you should have a Base BO that all of your BOs inherit from instead of inheriting directly from BusinessLayer.  In your BaseBO class, you will overwrite the FillDataTable command, and whichever other commands are necessary as you move down the road.  You will program all of your queries towards Oracle or Sql, whichever you prefer.  So for arguments sake, let's just assume you will program towards SQL Server.  When a FillDataTable is called, for example, you will be passing in an SqlDbCommand, all the time every time regardless of which backend you are running.  Then in your overwritten FillDataTable command in your BaseBO, you will know if you need to convert that SQLDbCommand into an OracleDbCommand (or whichever provider you are using).  This way all of the logic is encapsulated in the BaseBO and once it is tested, it is done.  This way you have 1 BO that represents a table...not one for SQL and one for Oracle....just one.  This will require a little bit of elbow grease, but this is the approach that we have taken on our medical software and it has worked well (we converted SqlDbCommands into OleDbCommands for VFP).