[AccessD] Access/SQL

I pretty much agree with the main points of the article however what is not mentioned is what .Net 
provides that VBA doesn't.  For simple apps Access is da bomb, but for complex requirements that 
include file parsing, directory watching, FTP, and so forth Access hits a wall.

And yea, yea, third party controls (see what the author says about them and apply to Access third 
party as well).

I'm about as capable in Access / VBA as anyone I know (I don't get out much ;) and I am learning 
.Net because of the limitations of Access.  I have working applications that are quite complex that 
I wish I could convert.

I also think that what can happen in .Net is that the people doing the programming might not always 
be fluent in the database side.  It is easy to hire .Net programmers, not so easy to hire database 
developers fluent in .Net.

John W. Colby
www.ColbyConsulting.com


Doug Steele wrote:
> It's a bit nit picky, but based on my somewhat limited ASP.NET development
> experience (one web/SQL based app)
> 
> 1. No multi column comboxes.  True, but easy enough to work around.  I've
> been moving away from multi column comboboxes in Access development anyway
> as I find them fiddly to debug (and this is me debugging my own code).
> 2. No paging.  Gridviews page very nicely.
> 3. Different form types:  Huh? Gridviews, Formviews, detailsview in .net.
> 4. Labels that move with controls.  Who cares?  Half the time when I'm
> working in Access I end up with unattached labels.
> 
> Again, based on my limited experience so far, it takes me at least 4X the
> time to develop a screen in C# that it would in Access; but I've got 10+
> years of Access experience and 100 or so hours of C#.  My fingers are
> already developing .net habits and I know that in a year or so I'll be way
> faster.
> 
> Doug
> 
> On Fri, Nov 13, 2009 at 8:02 AM, Jim Dettman <jimdettman at verizon.net> wrote:
> 
>> Doug,
>>
>>  What would you not agree with?
>>
>>