Noobie Question: Hooking a dataset into .MDB?

  • Thread starter Thread starter (Pete Cresswell)
  • Start date Start date
P

(Pete Cresswell)

I'm about to start climbing the .Net learning curve.

Would like to start by reproducing a little application that I already have up
and running using an MS Access front end. It manages information for class
reunions. Seems to have the basics: parent/child records, "Find"
functionality, Add/Change/Delete functionality....

However I don't want to develop just a client/server app shoehorned into .Net.
Instead, I'd like to go the whole nine yards and use .Net DataSets.

I'd like to minimize the number of new things TB dealt with.
Is it realistic to think about implementing DataSets against a JET back end?
(i.e. no stored procedures can be written)

Or should I just bite the bullet an migrate the back end to SQL Server?
 
(Pete Cresswell) said:
I'm about to start climbing the .Net learning curve.

Would like to start by reproducing a little application that I already
have up
and running using an MS Access front end. It manages information for
class
reunions. Seems to have the basics: parent/child records, "Find"
functionality, Add/Change/Delete functionality....

However I don't want to develop just a client/server app shoehorned into
.Net.
Instead, I'd like to go the whole nine yards and use .Net DataSets.

I'd like to minimize the number of new things TB dealt with.
Is it realistic to think about implementing DataSets against a JET back
end?
(i.e. no stored procedures can be written)

Or should I just bite the bullet an migrate the back end to SQL Server?
Click to expand...

You don't need to use stored procedures to create datasets. Any query can be
loaded into a dataset using the appropriate DataAdapter, in this case that
would be OleDbDataAdapter, I believe.
 
You could use a JET backend through the OleDbClients. Although I would
advise against it ;) Access isn't, in my opionon, a "database"(Not even a
real db, just a file) worth the fuss.

Don't really know what your app is doing, but the MSDE could be a cheap
substitue.
 
Patrik Lowendahl said:
You could use a JET backend through the OleDbClients. Although I would
advise against it ;) Access isn't, in my opionon, a "database"(Not even a
real db, just a file) worth the fuss.

Don't really know what your app is doing, but the MSDE could be a cheap
substitue.
Click to expand...

MSDE would work, but its a bit of a heavy hammer, don't you think?

If, in this case, this is simply a single user, small application, Access is
probably the right choice, if for no other reason than because it has the
smallest footprint and installation process.
 
If you want the full functionality of a database and the long term growth
potential that a database can offer by all means go to SQL Server. Has a bit
of a learning curve, but worth it in the long run.
 
RE/
Access isn't, in my opionon, a "database"(Not even a
real db, just a file) worth the fuss.

Don't really know what your app is doing, but the MSDE could be a cheap
substitue.
Click to expand...

100% agreement on the "not a real database"...I just have a limited number of
brain cells available, and wanted to isolate the UI and it's care/feeding from
the back end until I got up to some level of competance there....then I'd
migrate the back end.

This particular app, in it's present niche, actually is a classic
desktop/file-based DB situation. To wit, one user and only a few hundred
records. Temporarily avoding MSDE would also give me easier portability - i.e.
I could just copy a bunch of files to another computer to be able to play with
it somewhere else .... as opposed to having to install MSDE on somebody else's
box.
 
Patrick,
You could use a JET backend through the OleDbClients. Although I would
advise against it ;) Access isn't, in my opionon, a "database"(Not even a
real db, just a file) worth the fuss.
Click to expand...

The main difference between a database and a file is that you can change
data in it without reading the whole file and write it completly again or by
appending data to the end of it.

In my opinion does Access fullfill the first option and not the last.

So why is Access in your opinion not a database?

Cor
 
I fully agree with your point of a smaller footprint,

although I don't really agree with MSDE being a hammer, it's quite
lightweight IMHO. But as Pete pointed out in a later post, it does requires
different level of SQL knowledge.
 
1) There's no real indexing in Access, which makes query optimization
impossible.
2) It's not a server with separate memory managment, thread handling, and
separate process to isolate the database from the rest of the application
and operativsystem.

This is just two things from the top of my head, I haven't been involved in
any evaluation for Access since 2002.

Additionally I don't agree that you can't change data in a file without
loading the whole file. You could easily change rows in a file without
loading anything else then the row. Even in older technologys then .Net
(like vb 6, delphi) and C/C++ you have the possibility to just go to one row
and change the data in it.

So your point 1 would make Access either a file or a database, other factors
makes it a file.
 
Patrick
Additionally I don't agree that you can't change data in a file without
loading the whole file. You could easily change rows in a file without
loading anything else then the row. Even in older technologys then .Net
(like vb 6, delphi) and C/C++ you have the possibility to just go to one
row and change the data in it.
Click to expand...

This makes it in my opinion exactly a database, maybe not a SQL type
relational database, however the last is not the criteria to be a database.

The first databases where using random keys, the next relative adresses,
however definitly it where databases. And often much faster than the current
ones, however bad to manage.

Cor
 
Patrik Lowendahl said:
I fully agree with your point of a smaller footprint,

although I don't really agree with MSDE being a hammer, it's quite
lightweight IMHO. But as Pete pointed out in a later post, it does
requires different level of SQL knowledge.
Click to expand...

Its fairly lightweight, for someone who knows SQL Server. When I first moved
up to MSDE from Access, it wasn't pleasent. After using SQL Server 2000,
however, MSDE became as much of a cakewalk as any database server can be,
but before...

I assume this is the point about requiring a different level of SQL
knowledge(I can't seem to find that message).

More to the point is that, for a few hundred records(couldn't be more than a
classes worth of students, by the sounds of it), is there any point in
learning and lugging around MSDE when Access(Or even an XML file, if you are
up to taking a chance) would do admirably?

Also, the constant running server is a bit of a tax thats kind of useless,
IMHO.

The better choice would be a literal inprocess database, but I don't know of
one for .NET thats worth its salt. Every one I've seen has been java ports
that just don't fit the .NET model all that well.
--
Patrik Löwendahl [C# MVP]
www.cshrp.net - "Elegant code by witty programmers"

Daniel O'Connell said:
MSDE would work, but its a bit of a heavy hammer, don't you think?

If, in this case, this is simply a single user, small application, Access
is probably the right choice, if for no other reason than because it has
the smallest footprint and installation process.
Click to expand...
Click to expand...
 
Robert Ashby said:
If you want the full functionality of a database and the long term growth
potential that a database can offer by all means go to SQL Server. Has a
bit
of a learning curve, but worth it in the long run.
Click to expand...

When growth is approriate, yes.

Somehow I don't think this particular application is one thats going to
blossom into hundreds of thousands of rows.

I would simply design data access into a module that can be replaced. If
requirements change enough that a full database is needed, I would be
surprised if that wouldn't require significant overhauls to the data access
module anyway.
 
Back
Top