The BusinessLayer class should provide the following abstract methods:

• CreateSelectQueryInformation()
• CreateInsertQueryInformation()
• CreateUpdateQueryInformation()
• CreateDeleteQueryInformation()
• CreateSelectStoredProcQueryInformation()
• CreateInsertStoredProcQueryInformation()
• CreateUpdateStoredProcQueryInformation()
• CreateDeleteStoredProcQueryInformation()

The implementing business object classes should return a new QueryInformation object initialized with the appropriate QueryType and stored procedure settings and all of the field and table properties already initialized based on the underlying data structure.

This would greatly simplify generation of QueryInformation objects when writing code and facilitate their use querying.

Key word here being "suggests."   Here within lies the problem.  This type of functionality alone could become a full time business.  In fact, there are third party companies that have products that do nothing but act as in "go between" all database query types.  For example, if you prefer to "speak" in SQL Server, you create your queries in that syntax and if you need to have it spit out the Oracle, MySql, etc, then you just set an output property and the statement is altered to the desired language.

Though we will continue to add functionality to our QueryInfo class, we have never claimed, nor plan, to become a "full translation" company.  If you have this need, and you are planning on supporting several different languages, then you should search the internet for some of the 3rd party companies that have a translation product available or create your own class to meet your needs.

http://www.swissql.com/products/sqlone-apidotnet/sqlone-apidotnet.html

Additionally, with the advent of DLinq, this problem will ultimately resolve itself by removing all embedded SQL.  This will be a part of StrataFrame 2.0 (for use with .NET 3.0).

Thanks, I will look into that.