Classes, Access to DB & Deployment Project

[Sergio Terenas]

Hi,

I've actually read 2 books on VB .NET and ADO.NET but I've got a couple
doubts I can't figure out. Hopefully someone may shed some light on this.

If I'm to develop an application that handles, for instance, employees, how
should I go about and implement this ?

1. Should I create a class called "Employee" and have all fields defined in
it (ej. ID, Position, salary, name, etc, etc) and have this same structure
on a table ? If I need to make a change (add a field, etc) does it mean I
have to change de DB and also the class ? How would a pro do this ?

2. I read Datasets work disconnected from the DB. How does ADO.NET handle
concurrency ? Suppose I have two users modify the Employee table. Since
I'd use a disconnected Dataset, how would ADO.NET know which record is the
most recent one ? Is this automatically handled by ADO.NET or should I
write code to handle this ? Sorry, the book didn't dive into the details...

3. I understand how I can create a project to setup a package to be deployed
on the client PCs. Now, if I come up with an upgrade to the application
does the setup project handle the upgrade process replacing newers files and
leaving any configuration done by the user or would I have to uninstall and
install the new package ?

4. Last, I've seen many code snippets and sample applications on the
Internet but none that shows a full database application (Access would be
enough) with a GUI that shows many of the functionality VB.NET offers
(DataGrids, Combos, how to go about to connect to several tables, etc). Any
URLs you may point me to ?

Thanks for your help!

Greetings,

ST

 

[William \(Bill\) Vaughn]

Sergio,
What books have you read? Both David's and my books go through these
issues pretty thoroughly.
If you're just getting started (and it sounds like you are) using a separate
class to handle your data is too complex. If you don't have to scale to
thousands of users, the extra scalability you achieve with class-based
systems is probably not worth the work. We didn't hear much about how many
users (if any) you plan to support. We don't know what database engine you
plan to use. Access can indeed help create tables, but so can VS.NET.
If you create database tables, ADO.NET can add data to them and return it.
If you use the DataAdapter configuration wizard (DACW) VS.NET will build
simple data query and update code. Your "Employee" table can be created and
maintained entirely from ADO.NET code--we all do it. As you learn more,
you'll discover that the concurrency provided by ADO.NET is pretty
simplistic, but functional. As I said, most of good books walk you through
this.

When you fetch data into a disconnected recordset and change it, the code
generated by the DACW compares the data still on the server with what it
originally read. If it's different (because someone else changed or deleted
the row), the Update method fails and you'll have to decide what to do.
There are long discussions of the options in the books (or there should be).

ADO.NET or VB.NET deployment is very different than VB6. For the most part
it's simply a matter of copying files but the deployment wizard takes care
of these issues.

If you're not planning on buying VB.NET, you have your work cut out for you.
You'll spend years recreating the functionality.


--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________