>This is essentially what I will be doing (see my response to Alexandre), only I will likely do it by generating a string with a common syntax, and then just build a literal SQL string from the parameters. In any case, my base data class will have to know whether I am in OleDb (DBF) mode or SQL Server mode (nos difficult by using "is"), and then build the SQL string based on data type of the value (single quotes for text, converting numbers to character, curly braces for DBF dates, etc). Your method appears similar, except you build the string as you go instead of substituting for parameters after generating a base SQL string.

If you always use the parameterized approach, you will never need to worry about the delimiters, as far as the quotes go. This is one good thing of using such an approach. The same goes with .NET Boolean. For example, the following add various data types into the parameter collection. It uses .NET VB.NET syntax but the data class will make sure they are properly added as per the backend being used:

        loDataProvider.ParameterAdd("Active", True)
        loDataProvider.ParameterAdd("Street", "12 Main")
        loDataProvider.ParameterAdd("Expiration", 12)
        loDataProvider.ParameterAdd("DateCreated", Date.Now - 20)
        If Not loDataProvider.SQLUpdate("SELECT Member.FirstName " + _
         "FROM Member "+ _
         "WHERE " + loDataProvider.Logical("Member" , "Active" , True) + " AND " + _
         "Member.Street=" + loDataProvider.ParameterAddSQL("Street") + " AND " + _
         "Member.Expiration=" + loDataProvider.ParameterAddSQL("Expiration") + " AND " + _
         "Member.DateCreated>=" + loDataProvider.ParameterAddSQL("DateCreated")) Then
            Return False
        End If