Oracle and SQL BO for a single Windows GUI


Author
Message
Ross L. Rooker, Sr.
Ross L. Rooker, Sr.
StrataFrame User (245 reputation)StrataFrame User (245 reputation)StrataFrame User (245 reputation)StrataFrame User (245 reputation)StrataFrame User (245 reputation)StrataFrame User (245 reputation)StrataFrame User (245 reputation)StrataFrame User (245 reputation)StrataFrame User (245 reputation)
Group: Forum Members
Posts: 153, Visits: 462
Here is a sample setup to base my question:

  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.

Reply
Trent Taylor
Trent Taylor
StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 7K
If youa re trying to convert a BO type from one object type to another, this gets tricky.  It is possible, but will require some advanced reflection to get this done.  In essence, we do a bit of this when we translate a BO (i.e. a ChildFormDialog).  But in this instance, they are the same type on both sides.  To change the actual type of the object, the easiest way would be to follow a level of inheritance (Oracle inherits from the SQL DB BO) and then the partial classes would override the properties...this too could get tricky due to the same field names.

The best route would be to have all of this logic in a BO and change the dynamics of the BO to support both versions.  In other words, you could always bind to the SQL DB type.  Then in your base BO when a FillDataTAble or Save is called, the SQL would create an instance of the Oracle when trying to go to the server...or you could have a single BO instance and change the database.

This is not a simple question to answer, especially here on the forum like this.  But you are going to want to encapsulate this logic in the BO, not at the form level, otherwise it will be a nightmare to maintain your application.

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Threaded View
Threaded View
Ross L. Rooker, Sr. - 17 Years Ago
Trent L. Taylor - 17 Years Ago
Ross L. Rooker, Sr. - 17 Years Ago
Ross L. Rooker, Sr. - 17 Years Ago
Trent L. Taylor - 17 Years Ago
Ross L. Rooker, Sr. - 17 Years Ago
Trent L. Taylor - 17 Years Ago
Ross L. Rooker, Sr. - 17 Years Ago
Ross L. Rooker, Sr. - 17 Years Ago
Ross L. Rooker, Sr. - 17 Years Ago
Trent L. Taylor - 17 Years Ago
Ross L. Rooker, Sr. - 17 Years Ago
Ross L. Rooker, Sr. - 17 Years Ago
Greg McGuffey - 17 Years Ago
Ross L. Rooker, Sr. - 17 Years Ago
Edhy Rijo - 17 Years Ago
Dustin Taylor - 17 Years Ago
Ross L. Rooker, Sr. - 17 Years Ago
Dustin Taylor - 17 Years Ago
Ross L. Rooker, Sr. - 17 Years Ago
Ivan George Borges - 17 Years Ago
Ross L. Rooker, Sr. - 17 Years Ago
Ross L. Rooker, Sr. - 17 Years Ago
Greg McGuffey - 17 Years Ago

Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search