http://forum.strataframe.net/FindPost2051.aspx
I understand that the QueryInformation class was originally designed for internal use, but your public API exposes it as an option to hard-coded SQL statements and DBCommand objects. While your documentation correctly recommends using DBCommand objects rather than hard coded SQL statements, even DBCommand requires a SQL statement if a stored procedure is not being used. Best practices suggestes that SQL statements should not be embedded in source code due to differences between RDBMS vendors. The QueryInformation class eliminates this as an issue since it is consumed by the specific DbDataSourceItem implementation. That, in my mind, makes this the preferred approach for FillDataTable() and GetDataTable(). So, to make this as useful as possible, the WhereStatements need to include the missing WhereStatementTypeOptions.
The recommendation was not meant to be a quick fix. The actual coding is no big deal, but you are correct that the testing effort is certainly greater than the coding effort. I was just hoping that this enhancement request would make it in sometime in the not too distant future release.
The QueryInformation class was designed primarily for internal use (so that the business layer can save records and the browse dialog can search for records).
Adding that functionality might take a while to include all of the appropriate unit testing. We will review it at our next staffing meeting, and see if is appropriate to add to the enhancement list.
Add support for the following:
Of course, these additions will need to be supported in the various XxxxDataSourceItem classes.