[AccessD] Autonumber when?

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
>



More information about the AccessD mailing list