Cannot conceptulize how it should be done

J

jamesfreddyc

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
 
W

William Vaughn \(MVP\)

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

jamesfreddyc

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

jamesfreddyc

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
 
Top