[AccessD] Dot Net, where to start?

Jim Lawrence accessd at shaw.ca
Mon Apr 30 14:51:06 CDT 2007


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




More information about the AccessD mailing list