[AccessD] Dot Net, where to start?

Charlotte Foust cfoust at infostatsystems.com
Fri Apr 27 11:34:50 CDT 2007


You forgot to mention that there are umpteen ways to do a thing and NONE
of them is always the right way!  I haven't seen the need for
collections in .Net that exists in Access/VBA.  We do use them, but
classes and structures fill most of the need.  And by the way, classes
can have methods available from a direct call to a class object as well
as methods that can only be called through an instance ... In the same
class.  It's not all or nothing.

Charlotte Foust  

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of JWColby
Sent: Friday, April 27, 2007 9:23 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Dot Net, where to start?

I have no reason to doubt Arthur (or Shamil), it is simply that when it
comes to actually doing something in .Net I am still so far under water
that there is not even a glimmer of light.  Once I can actually see the
surface, then I will start looking at extraneous stuff like reporting.

<grin> 

I have "played" with .Net, both VS2005 and VB.Net express.  The IDE
itself is so vast that just getting comfortable with that is a job in
itself (which is why I recommend the Express for starters, it is more
limited but similar).  After you do that, becoming familiar with the
framework and all of its classes is another major job.  It is trivial to
build a form and get a button to click.  It is NOT TRIVIAL to (for
example) understand how collections are used, what the various types of
collections are and what they are used for and when to use them etc.  I
use collections EVERYWHERE in Access, but there is only one, and it only
has only 4 methods.  

EVERYTHING is an object in .Net.  Simple variables such as strings have
methods for formatting, cutting, pattern recognition etc.  All of the
"string stuff" that are functions in VBA are methods of the string
object in VB.Net.  Classes can be static (don't need to be instantiated)
or dynamic(?) have to be instantiated.  Getting at data isn't just set
"db = current db, set rst = db.open()".  There are FOUR different
objects and each of those objects have a ton of properties and methods.

And that is kind of my point, it seems to put the cart before the horse
to be worrying about reporting if you can't even use a collection
correctly yet.  There is a LOT to do to get comfortable here.  Get a
copy of VBA.Net Express and dig in.  Once you can write code in it as
easily as you can in VBA, then take a breath and worry about the other
stuff.  

I have a very real problem that I simply have too much (ACCESS) work to
do, I can't even look up during the day, and I now have two kids as well
taking up my evenings.  My time to "play around" in .Net has been pretty
limited, and there is so much to know that it takes awhile to get
familiar.  But I am trying.

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Friday, April 27, 2007 11:53 AM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Dot Net, where to start?

Hi Arthur, Shamil, Charlotte and John

Now I'm slightly confused. I would prefer to believe in Arthur's words
as I like John don't have the VS 2005 Pro version, but I have to listen
to Shamil and Charlotte in this matter. For most of the projects I may
encounter, reporting will be an important part.

Or are we talking about reporting "power" in different directions?

/gustav


--
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