[AccessD] Convert Access App to VB.Net (was FYI: Good news -VBA in Office 12 and beyond...)

Steve Erbach erbachs at gmail.com
Tue Feb 21 16:04:44 CST 2006


Charlotte,

Very good little summary of the features/benefits of using .NET.

Could you tell me what resources you've used to support your learning
curve?  That is, books, on-line code samples, hands-on courses,
magazines, web sites, etc.  Do you have any "mentors"?  People who you
think are tops when it comes to writing about .NET or coding in .NET?

Thanks,

Steve Erbach
Neenah, WI
http://TheTownCrank.blogspot.com


On 2/21/06, Charlotte Foust <cfoust at infostatsystems.com> wrote:
> I don't know where to start, Dan.  It would be a total rewrite, but the
> program logic could be used to build the new app.  Learning curve is
> steep because *everything* is an object and doing anything to it (like
> populating a string that already has text) creates a NEW object with the
> same name.  You don't do things the same way, but it is much easier to
> get at and manipulate data, to create datasets that include related
> fields from another table, to create reusable code.  The list is
> endless.  ADO.Net is GREAT, and I *liked* ADO.  Building forms and user
> controls is quite different from Access because you have so much control
> over the objects and their behavior.  Reports can be used in our
> web-based app or on Windows without modifications.  Do you want to bind
> different parts of a form or report to different data sources?  No
> problem.  Do you want to bind controls to the top, left, right, bottom
> of the container so they move when the object resizes?  No problem.  Do
> you want a panel to fill its allocated space and stay that way through
> form resizes?  No problem.  Do you want custom behavior from a control?
> Create your own and use it in you apps.
>
> I'm a fan, as you can tell, but it is also easier to sell clients on
> .Net apps than on Access applications, justifiably or not.  We build our
> apps so that we can connect to either an Access or SQL Server backend
> without changing any of the code, which makes it easy to switch a client
> over when they need the added capacity of SQL Server.  It takes planning
> and learning and effort, so don't do it unless you are willing to commit
> to those things and you are willing to use managed code.  There is no
> point at all in building one-off code in .Net.  That's a waste of time
> and energy.
>
> Charlotte Foust
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters
> Sent: Tuesday, February 21, 2006 11:22 AM
> To: 'Access Developers discussion and problem solving'
> Subject: Re: [AccessD] Convert Access App to VB.Net (was FYI: Good news
> -VBA in Office 12 and beyond...)
>
>
> OK Charlotte,
>
> What are these goodies?  And the big question - what does it take to do
> the conversion (software, learning curve time, how to make reports,
> convert forms vs. modules vs. reports, etc.)
>
> For an Access application that has ~50K lines of code, is it worth it?
>
> Thanks!
> Dan



More information about the AccessD mailing list