Have just installed the newly purchased version 2.4. Set the Business Layer Generator (BLG) loose on my 233 table MSSQL 2005 database. During the finishing phase BLG begins to update the database with the generated sprocs but encounters an exception due to MSSQL not liking the column named "Key" in the SELECT or SELECTBYPK sprocs for the culprit table "Participant". Even though the column is defined within MSSQL as "[Key]" (without the quotes, of course, but WITH the brackets), it is seen as "Key" by BLG treeview and by the code generation classes as evidenced by the results of clicking the View Sql button. Noticeable in the generated scripts is the fact that in the INSERT and UPDATE scripts, the column names are encased in "[" and "]". But the column names are NOT encased in the SELECT and SELECTBYPK scripts.

I inspected the BLG code and detected that mmCodeGeneratorSql.GenerateInsertSprocStrings() and mmCodeGeneratorSql.GenerateUpdateSprocStrings() utilize the parameters: tableNameDelimitBegin and tableNameDelimitEnd to indeed encase the column names, but mmCodeGeneratorBase.GenerateSelectSproc() and mmCodeGeneratorBase.GenerateSelectByPKSproc() do NOT utilize those parameters.

I would test my theory but I am unable to successfully build the MMBusinessLayeGenerator solution due to missing resources (the \Resources directory is empty) and a failure of the post build directive (Copy "$Target...)!


Realistically I should and will change the offending column names ("Key" is not the only one) as this MSSQL database is an import from another DB vendor's Data Dictionary. But multi-part column names - such as "First Name" - although probably not good practice, are legitimate column names in MSSQL and are internally handled with the bracket encasing. I think for consistency sake we should probably encase the column names in all forms of stored procedure - the table name was certainly covered everywhere.

TIA
TonyK.