[AccessD] Autonumber when?

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