jwcolby
jwcolby at colbyconsulting.com
Wed Apr 6 16:20:08 CDT 2011
;) John W. Colby www.ColbyConsulting.com On 4/6/2011 4:58 PM, David McAfee wrote: > 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 >>