New to VB.NET and need a bit of advice for re-writing all VB6 apps in
VS2008/VB.NET --- any replies are greatly appreciated.

Previous app design included DataAccess (SQLServer/Sprocs) by individual
Classes "mapped" to the individual SProcs on SQLServer 2005 db. For ex,

"SRCustomers" is a StoredProc (Solely a SELECT with 4 INNER JOINS, recieved
2 parameters)

and...

"rsSRCustomers" is A ClassModule for creating recordset
(Public WithEvents rsSRCustomers as ADODB.Recordset)
So, it was very easy to create/destroy this rs throughout the entire
application.

From what I can tell, I am inclined to go with an SQLDataReader (for now, I
just need to create SELECTS).

Questions:

1. I was using those ADOrecordsets for use in other libraries (ArcObjects
for creating spatial data layers/shapefiles). So, can I use DataTables in
the same manner as an ADOrecordset?

2. How do I implement a logical approach to building on Module as a
DataAccessLayer? Ideally, I'd like to put all of the various data access
proc's in one Module. Is this a good approach? Alternatives?


Thanks,

j

Welcome to .NET...
First, I would toss out what you know about VB6 and ADO classic as both
VB.NET and ADO.NET are very different. The DataReader is the "pipe" or
stream of resultsets connected to the data source via a Connection. It's
used by the TableAdapter or (obsolete) DataAdapter Fill methods. There are
no "Recordsets" or cursors in ADO.NET--just disconnected rowsets. Yes, the
DataTable is the mechanism used to manage data once fetched via a Command
execute call.

Can you use DataTables in the same was as Recordsets against middle-tier
components? No, not really--not if they're designed to extrude or accept
Recordsets. Yes, it might make sense to put all of the data access
components into a single model or better yet, into an object library as
discussed in Rocky Lhotka's books.

I expect my book (which is written specifically for developers starting out
with .NET) would also help.
--
__________________________________________________________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
http://betav.com/blog/billva
http://betav.com
____________________________________________________________________________________________



"jamesfreddyc" <(E-Mail Removed)> wrote in message
news:3CD6AC2B-174E-4664-A99B-(E-Mail Removed)...
> New to VB.NET and need a bit of advice for re-writing all VB6 apps in
> VS2008/VB.NET --- any replies are greatly appreciated.
>
> Previous app design included DataAccess (SQLServer/Sprocs) by individual
> Classes "mapped" to the individual SProcs on SQLServer 2005 db. For ex,
>
> "SRCustomers" is a StoredProc (Solely a SELECT with 4 INNER JOINS,
> recieved
> 2 parameters)
>
> and...
>
> "rsSRCustomers" is A ClassModule for creating recordset
> (Public WithEvents rsSRCustomers as ADODB.Recordset)
> So, it was very easy to create/destroy this rs throughout the entire
> application.
>
> From what I can tell, I am inclined to go with an SQLDataReader (for now,
> I
> just need to create SELECTS).
>
> Questions:
>
> 1. I was using those ADOrecordsets for use in other libraries (ArcObjects
> for creating spatial data layers/shapefiles). So, can I use DataTables in
> the same manner as an ADOrecordset?
>
> 2. How do I implement a logical approach to building on Module as a
> DataAccessLayer? Ideally, I'd like to put all of the various data access
> proc's in one Module. Is this a good approach? Alternatives?
>
>
> Thanks,
>
> j
>
>

> First, I would toss out what you know about VB6 and ADO classic as both
> VB.NET and ADO.NET are very different.

I'm finding it VERY difficult to toss those concepts out -- it's all I
really have to go on! But I can see exactly what you mean as I iterate
through the various concepts and samples.


> Yes, it might make sense to put all of the data access components into a single model


Is there any example of a DataAccessLayer out there? I'd love to see how
disparate datasets are disseminated from SQLServer and consumed by the
applicaiton, especially if it's similar to my situation: Sprocs on
SQLServer2005 returning datasets. I really just don't need anything more
than simple sets (or "rows") of data coming from SELECT sprocs.

Gosh I hope that makes sense.




"William Vaughn (MVP)" wrote:

> Welcome to .NET...
> First, I would toss out what you know about VB6 and ADO classic as both
> VB.NET and ADO.NET are very different. The DataReader is the "pipe" or
> stream of resultsets connected to the data source via a Connection. It's
> used by the TableAdapter or (obsolete) DataAdapter Fill methods. There are
> no "Recordsets" or cursors in ADO.NET--just disconnected rowsets. Yes, the
> DataTable is the mechanism used to manage data once fetched via a Command
> execute call.
>
> Can you use DataTables in the same was as Recordsets against middle-tier
> components? No, not really--not if they're designed to extrude or accept
> Recordsets. Yes, it might make sense to put all of the data access
> components into a single model or better yet, into an object library as
> discussed in Rocky Lhotka's books.
>
> I expect my book (which is written specifically for developers starting out
> with .NET) would also help.
> --
> __________________________________________________________________________
> William R. Vaughn
> President and Founder Beta V Corporation
> Author, Mentor, Dad, Grandpa
> Microsoft MVP
> (425) 556-9205 (Pacific time)
> Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
> http://betav.com/blog/billva
> http://betav.com
> ____________________________________________________________________________________________
>
>
>
> "jamesfreddyc" <(E-Mail Removed)> wrote in message
> news:3CD6AC2B-174E-4664-A99B-(E-Mail Removed)...
> > New to VB.NET and need a bit of advice for re-writing all VB6 apps in
> > VS2008/VB.NET --- any replies are greatly appreciated.
> >
> > Previous app design included DataAccess (SQLServer/Sprocs) by individual
> > Classes "mapped" to the individual SProcs on SQLServer 2005 db. For ex,
> >
> > "SRCustomers" is a StoredProc (Solely a SELECT with 4 INNER JOINS,
> > recieved
> > 2 parameters)
> >
> > and...
> >
> > "rsSRCustomers" is A ClassModule for creating recordset
> > (Public WithEvents rsSRCustomers as ADODB.Recordset)
> > So, it was very easy to create/destroy this rs throughout the entire
> > application.
> >
> > From what I can tell, I am inclined to go with an SQLDataReader (for now,
> > I
> > just need to create SELECTS).
> >
> > Questions:
> >
> > 1. I was using those ADOrecordsets for use in other libraries (ArcObjects
> > for creating spatial data layers/shapefiles). So, can I use DataTables in
> > the same manner as an ADOrecordset?
> >
> > 2. How do I implement a logical approach to building on Module as a
> > DataAccessLayer? Ideally, I'd like to put all of the various data access
> > proc's in one Module. Is this a good approach? Alternatives?
> >
> >
> > Thanks,
> >
> > j
> >
> >

Ok,

I was finally able to get my first DataAccess run going. Holy cow is this
stuff F-A-S-T. Just a simple Windows form with 2 DateTimePicker controls and
a DataGridView. The 2 dates are added to parameters of a command and passed
into a single StoredProcedure.

I may not fully understand why, perhaps it has to do with the connection
pooling, but on subsequent queries by changing the date values, the Grid is
populated with lightning quick efficiency. AND I absolutely love the fact
that the grid can be sorted without any further code to write (good gosh
almighty, I don't think I ever got my old DataGrids/ADOrs's to sort
correctly).

Anyway --- at this point all of the code is in the Form and will be looking
into building a better DataAccess layer/module to handle everything. But I
am happy to have gotten this far today.

j

"William Vaughn (MVP)" wrote:

> Welcome to .NET...
> First, I would toss out what you know about VB6 and ADO classic as both
> VB.NET and ADO.NET are very different. The DataReader is the "pipe" or
> stream of resultsets connected to the data source via a Connection. It's
> used by the TableAdapter or (obsolete) DataAdapter Fill methods. There are
> no "Recordsets" or cursors in ADO.NET--just disconnected rowsets. Yes, the
> DataTable is the mechanism used to manage data once fetched via a Command
> execute call.
>
> Can you use DataTables in the same was as Recordsets against middle-tier
> components? No, not really--not if they're designed to extrude or accept
> Recordsets. Yes, it might make sense to put all of the data access
> components into a single model or better yet, into an object library as
> discussed in Rocky Lhotka's books.
>
> I expect my book (which is written specifically for developers starting out
> with .NET) would also help.
> --
> __________________________________________________________________________
> William R. Vaughn
> President and Founder Beta V Corporation
> Author, Mentor, Dad, Grandpa
> Microsoft MVP
> (425) 556-9205 (Pacific time)
> Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
> http://betav.com/blog/billva
> http://betav.com
> ____________________________________________________________________________________________
>
>
>
> "jamesfreddyc" <(E-Mail Removed)> wrote in message
> news:3CD6AC2B-174E-4664-A99B-(E-Mail Removed)...
> > New to VB.NET and need a bit of advice for re-writing all VB6 apps in
> > VS2008/VB.NET --- any replies are greatly appreciated.
> >
> > Previous app design included DataAccess (SQLServer/Sprocs) by individual
> > Classes "mapped" to the individual SProcs on SQLServer 2005 db. For ex,
> >
> > "SRCustomers" is a StoredProc (Solely a SELECT with 4 INNER JOINS,
> > recieved
> > 2 parameters)
> >
> > and...
> >
> > "rsSRCustomers" is A ClassModule for creating recordset
> > (Public WithEvents rsSRCustomers as ADODB.Recordset)
> > So, it was very easy to create/destroy this rs throughout the entire
> > application.
> >
> > From what I can tell, I am inclined to go with an SQLDataReader (for now,
> > I
> > just need to create SELECTS).
> >
> > Questions:
> >
> > 1. I was using those ADOrecordsets for use in other libraries (ArcObjects
> > for creating spatial data layers/shapefiles). So, can I use DataTables in
> > the same manner as an ADOrecordset?
> >
> > 2. How do I implement a logical approach to building on Module as a
> > DataAccessLayer? Ideally, I'd like to put all of the various data access
> > proc's in one Module. Is this a good approach? Alternatives?
> >
> >
> > Thanks,
> >
> > j
> >
> >

FYI: I Found the info source I desired.

http://msdn.microsoft.com/en-us/library/ms978496.aspx

Since I am developing Add-in solutions (for ArcGIS), I don't necessarily
need to take in all of the concepts offered by the author. But there's tons
of great information there and I will take what I need to work into my
implementation.

j

"jamesfreddyc" wrote:

> New to VB.NET and need a bit of advice for re-writing all VB6 apps in
> VS2008/VB.NET --- any replies are greatly appreciated.
>
> Previous app design included DataAccess (SQLServer/Sprocs) by individual
> Classes "mapped" to the individual SProcs on SQLServer 2005 db. For ex,
>
> "SRCustomers" is a StoredProc (Solely a SELECT with 4 INNER JOINS, recieved
> 2 parameters)
>
> and...
>
> "rsSRCustomers" is A ClassModule for creating recordset
> (Public WithEvents rsSRCustomers as ADODB.Recordset)
> So, it was very easy to create/destroy this rs throughout the entire
> application.
>
> From what I can tell, I am inclined to go with an SQLDataReader (for now, I
> just need to create SELECTS).
>
> Questions:
>
> 1. I was using those ADOrecordsets for use in other libraries (ArcObjects
> for creating spatial data layers/shapefiles). So, can I use DataTables in
> the same manner as an ADOrecordset?
>
> 2. How do I implement a logical approach to building on Module as a
> DataAccessLayer? Ideally, I'd like to put all of the various data access
> proc's in one Module. Is this a good approach? Alternatives?
>
>
> Thanks,
>
> j
>
>

check 2