Not sure this will help your over all issue, but the FillDataTable isn't every called by the maintenance form....It never knows how you're going to need to fill your data. However, it is the root method that will get called any time you do fill the BO. Thus, any time you fill the BO, you will either call this method or write a method that ends up calling this method.

Could it be that the BO is a Smart BO and not using the FillDataTable method? IE... the SF Maintenance browse automatically fills the BO without any custom fill methods.

I did do the following as you suggested:

1. Create a base business object

2. Inherit all of your application BOs from this base BO

3. Within the base BO, override the FillDataTable method. 

Couple of questions.

1. On a Strataframe Maintenance form when is the FillDataTable method called? IE.. when to user SEARCHES on the Browse?, When the user clicks on SAVE?

2. Currently it appears that the Overridden FillDataTable method is not being executed from the BO that inherits from my BaseBO form although it appears that everything is set as you suggested. Is there something else I need to do?

This is not a quick sample to write and would ultimately involve me writing your entire base logic for you.  This is something that falls outside of the scope of this forum and falls on the side of consulting.  I have provided you with as much detail above as I could think of to get started.  You are welcome to post additional questions as you work through your solution as that is the intention of this forum.  We try to provide new samples and so I will add this to the list of possible future samples, but this will not be anything done in the near term. 

Please respond ASAP to my prior question in this thread in that I need to report back to my Team. Thanks.

Could you show me a sample on how to do the above with the simple example I provided above?

Trent

This would be ideal if it were incorporated into the framework. As you pointed out, this will require quite a bit of work. Based on my example, I can't help but believe that it would be extremely helpful to many other members to see a detailed example of how this is actually done. Your expertise is highly valued by everyone on the forum.

Thanks

Ross

Based on your code, this would require me to spend a fair amount of time and just write it for you which outstrips the scope of this forum.  But here are the basic steps:

1. Create a base business object
2. Inherit all of your application BOs from this base BO
3. Within the base BO, override the FillDataTable method.  You will want to massage the command before being passed into the base class.
   
   
   Public Overrides Sub FillDataTable(ByVal CommandToExecute As System.Data.Common.DbCommand)
       MyBase.FillDataTable(Me.MassageCommand(command))
   End Sub
   
   
4. The MassageCommand Method takes the native DbTypes into account to see if they need to be converted (this has to do with some internal logic of our BOs, you may need to provide additional logic here for Oracle support):
Private Function MassageCommand(ByVal Command As DbCommand) As DbCommand
'-- Get a reference to the command
Dim cmd As SqlCommand = DirectCast(Command, SqlCommand)

'-- If this business object needs to talk to Oracle, then convert the command, else, just execute it
If Me.ShouldNativeDbTypesBeConverted Then
    '-- Replace the char fields before converting the command
    For Each field As CharEnumField In _CharFieldsToUpdate
        field.ReplaceCharFieldWithEnumField(cmd)
    Next

    Return Me.ConvertCommand(cmd)
Else
    Return Command
End If
End Function



5. Within this command, you can see the ConvertCommand, this is where the meat of the conversion will take place.  You may need some RegEx logic here, but if you predominantly use sprocs, it makes this part easier.
   
   

   ''' <summary>
   ''' Converts the specified SqlCommand object into an equivalent OleDbCommand object.
   ''' </summary>
   Private Function ConvertCommand(ByVal Command As SqlCommand) As OleDbCommand
   '-- Establish locals
   Dim loReturn As New OleDbCommand()
   Dim loMatch As Match

   '-- Set the basic properties on the oledb command
   loReturn.CommandText = Command.CommandText
   loReturn.CommandType = Command.CommandType

   '-- Update the parameters for the command
   '-- Find all of the parameters within the text & replace them
   loMatch = _ParameterRegex.Match(Command.CommandText)
   loReturn.CommandText = _ParameterRegex.Replace(Command.CommandText, "?")

   '-- Replace the matches in the text and build the parameters for the command
   While loMatch.Success
       '-- Add the new parameter to the collection
       loReturn.Parameters.Add(ConvertParameter(Command.Parameters(loMatch.Value)))

       '-- Go to the next match
       loMatch = loMatch.NextMatch()
   End While

   '-- Return the new command
   Return loReturn
   End Function

In the last example, you can see that this is converting an SqlDbCommand into an OleDbCommand (geared towards VFP).  This is where you will have to spend a fair amount of your time, but this is the approach that you will want to take.

Trent

Based on my example, would it be possible for you to illustrate some code on how this is done? Or are you aware of something similar that I can use to get started?

Thanks

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).