[AccessD] Dot Net, where to start?

JWColby jwcolby at colbyconsulting.com
Mon Apr 30 16:35:58 CDT 2007


One of my problems with all of the database books is that all assume that
you are going to bind to a form.  Yea, that is important but once you get
past the data input / display, you still have data manipulations to do. 

I converted the code to find the population within a radius of a zip code.
Other than the fact that it took me a dozen hours to cut/paste/fix code that
was already written, it appears that something is just slightly off in the
calcs.  It looks to me like rounding errors across a dozen calcs is causing
the numbers to come out slightly larger.  Math.sin (for example) has a few
decimal points more accuracy (waaay out there to the right) than the VBA
cousins and I suspect that it is causing slightly larger values multiplied
by slightly larger values ^ slightly larger values to ripple out to
significantly larger values.

We'll see.

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 Charlotte Foust
Sent: Monday, April 30, 2007 4:55 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Dot Net, where to start?

In .Net, you ALWAYS have to think about what you're instructing the language
to do.  You can't rely on the default methods or properties the way we could
in Access, so if you want to populate a textbox, you use the Value property.
I've worked in it long enough so that I find it easier than Access in almost
every way and when I go back to Access, I keep looking for things I can't
find there!  It never becomes as effortless as Access code because the
object model is much vaster, and you don't have the advantage of DAO being
optimized for the UI to save time and effort.

We (like a lot of shops) use some 3rd party tools instead of the basic
Windows controls and reports.  The 3rd party tools are heavily enhanced
versions of the built in stuff with far more control available to the
programmer.  If you think .Net looks intimidating, take a look at
Infragistics controls and the levels of properties you have to work with!

Charlotte Foust

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of JWColby
Sent: Monday, April 30, 2007 1:42 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Dot Net, where to start?

>I see the progress more as a migration process something like a 90 
>degree
turn not as a 180.

And of course that depends on how much programming you do in VBA.  The more
you do, the harder it is in one sense and the easier in another.
It is harder because you already get so much accomplished so quickly in VBA
and can't believe how tough it is to get anything done in VB.Net (at first
anyway).  The easier it is in the sense that you are already an accomplished
programmer and "only" have to come up to speed on the differences.  

If only there weren't so many damned differences!!!  I am trying to take the
contents of a text box and place it into a single variable.
Uhh-Uhhhh!  In VBA you would get an automatic conversion but in VBA it
(apparently) tries to stuff a control type into a single type and complains
vigorously.  Now ya'd think that if there is a textbox.ToString method there
would be a ToSingle method right?

I'm back to screaming "just do what I WANT, NOT what I SAY!!!".  My computer
yells back, and it isn't something I can repeat in public.

And of course, in X thousands of hours all that will be behind me and I will
type VB.NET code the way I type VBA code now.  Forgetting all the pain (that
is the human mind for ya) I will wonder why I didn't convert years ago.  

In the meantime I have ordered massive quantities of painkillers from my
favorite internet pharmacy using those spam emails I receive so many of
every week.

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 Jim Lawrence
Sent: Monday, April 30, 2007 3:51 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Dot Net, where to start?

Hi All:

My 2 cents on this is that most if not all developers on the Access List are
working on or/and will be moving towards Dot Net at one point. I see the
progress more as a migration process something like a 90 degree turn not as
a 180.

Jim

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust
Sent: Monday, April 30, 2007 10:55 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Dot Net, where to start?

Does it belong in this list?   Also, there are differences between VS
2003 and VS 2005 when it comes to creating typed datasets.

Charlotte 

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

Hi Charlotte

Yes, that sounds like a learning experience.

/gustav

>>> kp at sdsonline.net 30-04-2007 04:31 >>>
Charlotte - any chance of stepping us dot net newbies thru an example of
what you mean? 

Kath
  ----- Original Message -----
  From: Charlotte Foust
  To: Access Developers discussion and problem solving
  Sent: Saturday, April 28, 2007 2:18 AM
  Subject: Re: [AccessD] Dot Net, where to start?


  The chapters on ADO.Net give a good overview of datasets, data providers
  and the actual relational objects (tables, views, etc.), and it also
  compares ADO.Net and ADO as well.  But I haven't seen any books
  describing the data tier structures in the way we built them.  Most of
  the books start with directly binding a form to a data adapter, and we
  work the other way around.  We build data "entities" that implement
  typed datasets and expose the behaviors and methods we need.  We can
  then drop one of those entities on a form or report to provide the data
  connections we need.  The working code is actually in a dataprovider
  class with the entity containing calls to the dataprovider and even to
  other entities if need be.

  Our model has evolved as we developed the apps and figured out what
  worked, and we have "refactored" (a much overused work in our shop) the
  bits and pieces many times over the course of the past two years.  

  Charlotte Foust 



--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

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