[AccessD] Dot Net, where to start?

I would suggest, it is somewhere between 90 and 180 degrees,
just so it could be an obtuse angle.

Jim Lawrence wrote:

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

-- 
Marty Connelly
Victoria, B.C.
Canada