I know that this command in the programs file will show you the actual command sent to the backend: MicroFour.StrataFrame.Data.DataBasics.DataSources[0].SetDebugOn("C:\\ValetLog.html", true);

What command would I insert in my base bo to get this command when SAVE is clicked. That would get me the INSERTs and UPDATEs. Then what command would I use to get the DELETE. Lastly what method in the BO would these commands be placed. 

 

Well, actually, now that I think about it, if you want to capture the same content as the debug mode, you will have to create your own DbDataSourceItem.  The easiest thing to do would be to copy over the SqlDbDataSourceItem or Oracle, whichever you are using, and create your own in your project. The method that you will need to place your logic is in the InternalExecuteNonQuery method.  This is what it looks like at the moment:

''' <summary>
        ''' Executes the given DbCommand with ExecuteNonQuery with debugging.
        ''' </summary>
        Protected Function InternalExecuteNonQuery(ByVal Command As DbCommand, ByVal IsTransactional As Boolean, ByVal TransactionKey As String) As Integer
            If Me._InternalExecuteNonQuery IsNot Nothing Then
                Return Me._InternalExecuteNonQuery(Command, IsTransactional, TransactionKey)
            Else
                '-- Show the debugging window
                Me.DebugCommand(Command)

                '-- Make sure the connection is open
                If Command.Connection.State <> ConnectionState.Open Then
                    Command.Connection.Open()
                End If

                '-- Execute the command
                Dim lnReturn As Integer = Command.ExecuteNonQuery()
                If Not IsTransactional AndAlso Me.ForceConnectionCloseOpen Then
                    Command.Connection.Close()
                    Command.Connection.Open()
                End If
                Return lnReturn
            End If
        End Function

So to do what you are trying to do would require that you copy over the full class (since at the moment this method is not overridable) and then insert your logic in the above method around the DebugCommand logic to get what you are looking for.  The reason is that this is the base location that actually builds the Command.  When a BO is saved, it uses the QueryInfo class that gets handed down to the DbDataSourceItem (Data Layer) that calls the appropriate Build command to produce the actual DbCommand.  This is how a BO can just swap out the back-end and connection logic, otherwise the BO would be hard coded to that data source.

I will see if we can add a potential event in a future build to capture this, but the downside is that an event would be called and could slow this process down.  The best way really is to do this at the DbDataSourceItem level.  The only other thing that would help is to make all of these methods overridable so that inheritance would work in this case.  This much we can do without any issue or performance bottleneck.