[quoted text, click to view]

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.

"Patrik Lowendahl [C# MVP]" <patrik.lowendahl@csharpsweden.com> wrote in
message news:uxG1SMxrEHA.4032@TK2MSFTNGP12.phx.gbl...
[quoted text, click to view]

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.

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?


--

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 Löwendahl [C# MVP]
www.cshrp.net - "Elegant code by witty programmers"

[quoted text, click to view]

RE/
[quoted text, click to view]

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,

[quoted text, click to view]

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.

--
Patrik Löwendahl [C# MVP]
www.cshrp.net - "Elegant code by witty programmers"

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:edFV9ZxrEHA.2136@TK2MSFTNGP14.phx.gbl...
[quoted text, click to view]

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.

--
Patrik Löwendahl [C# MVP]
www.cshrp.net - "Elegant code by witty programmers"

[quoted text, click to view]

Patrick

[quoted text, click to view]

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 [C# MVP]" <patrik.lowendahl@csharpsweden.com> wrote in
message news:OzsCuz3rEHA.192@tk2msftngp13.phx.gbl...
[quoted text, click to view]

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.
[quoted text, click to view]

[quoted text, click to view]

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.