David McAfee
davidmcafee at gmail.com
Wed Apr 6 15:58:29 CDT 2011
Perfect time to rewrite it for "unbound" >:P On Wed, Apr 6, 2011 at 1:38 PM, jwcolby <jwcolby at colbyconsulting.com> wrote: > I hear you Ken. > > I have written a framework for MDB BEs. It is very large, and has tons of > functionality, and was never intended to run against SQL Server simply > because nobody was using that back when I wrote it. > > Now I am trying to use it for a SQL Server back end. It is not just a > simple case of "write a library for this and a library for that. > Additionally I need it to work where this table (or set of tables) is kept > in an MDB and that one is moved to SQL. > > I write frameworks. The framework does a ton of stuff which is handled > automatically. It handles the not in list and the dbl click of combos for > example. The dbl click of a combo opens a form and moves to the record that > the combo is displaying. Classes instantiate classes which instantiate > classes. > > I am just not sure that "writing separate libs" is a viable option. It > would mean a complete rewrite of the framework and then a complete rewrite > of the FE. > > John W. Colby > www.ColbyConsulting.com > > > On 4/6/2011 4:13 PM, Kenneth Ismert wrote: > >> >>> jwcolby >>> ... >>> The code needs to work whether going to an MDB or SQL BE. The code works >>> fine for an MDB BE but fails for a SQL BE. >>> ... >>> >>> >> John, >> >> This is probably what you are trying to avoid, but I'll say it anyway: >> >> You should write separate code to handle the MDB and SQL Server BEs. >> >> First, the obvious: Jet and SQL Server are very different. >> * It is unlikely that this is the only variation you will have to account >> for throughout your code >> * Variations in code make it harder to test >> * When you do want to use SQL Server-specific features, like stored >> procedures, you will have to split the code anyway >> * I have a personal distaste of "On Error Resume Next" coding, which I >> use >> only for object cleanup code where there is literally nothing to raise an >> error to. >> >> All told, the cost and effort to make a large existing code base generic >> will likely exceed the cost of just splitting it neatly into libraries >> that >> support each database type. >> >> Plus, you get more modular, flexible, testable code. >> >> Again, this is what you are trying to avoid, but I felt I should say it, >> anyway. >> >> -Ken >> > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >