Hi Erik

The first thing i didn't like about the ComCodebook is the fact that anytime your data (the SQL Statements) or your business rule changes you the need to modify your code. It is not practical in a production environment and makes the application very unflexible and harder to maintain.
Don't get me wrong here, i don't think COMCodebook is all bad, in fact i think it is a great starting point to learn n-tier development. So after a little study on it, i modified it so it contains very few funtions, i created external tables (They can live on MSSQL, VFP, or any other data source), The tables contain all the parameters needed to create an validate an ADO RecordSet.

So the data connection parameters, Cursor definitions, And validation rules are all stored in tables. No need to update DLL's. Then i created some wizards to populate the parameters tables.

Second thing i did not like much is if you design large application containing many cursors and as many cursor object ( Our application contain more than 1500 of them) when a client creates a instance of one of the object, it take forever to initiate since they contain so many PEM's

My original post was more about how robust and well design COMCodebook is in a very thecnical point of view.

Thanks


>>Did Anyone here looked at the ComCodeBook ? In a technical point of view what did you think of it. I personnaly looked at it and a couple of things don't seem to be right.
>
>What don't you like, or what is broken?