A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » General Discussion
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Opening Access db via DAO in vb.net



 
 
Thread Tools Display Modes
  #41  
Old February 4th, 2008, 01:02 PM posted to microsoft.public.access,microsoft.public.dotnet.framework.adonet,microsoft.public.dotnet.languages.vb
Arvin Meyer [MVP]
external usenet poster
 
Posts: 4,231
Default Opening Access db via DAO in vb.net

No one ever said that either DAO or ADO fit into .NET. The problem posed was
how to get at the data in a JET database using .NET.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

"Cor Ligthert[MVP]" wrote in message
...
Arvin,

DOA and ADO don't really fit in .Net.

You can use it, as you can use as you want probably even a punch card
reader which has drivers for Windows, but therefore a punch card reader is
not a part of Net.

Cor



  #42  
Old February 4th, 2008, 01:23 PM posted to microsoft.public.dotnet.framework.adonet,microsoft.public.dotnet.languages.vb,microsoft.public.access
Arvin Meyer [MVP]
external usenet poster
 
Posts: 4,231
Default Opening Access db via DAO in vb.net

The business solution I described was perfect for using JET as the data. It
was stable, and secure in its designed usage, and had been working for
years. It had about 100 MB of data, at least a third of which could have
been archived. What is wasn't was an enterprise solution. For that, there
were 2 choices, customize it as necessary for each of the 23 divisions, and
periodically, send the financials to the existing mainframe solution, or
build a SQL-Server back-end that would be used by all the divisions.

Actually, the first choice (i.e. customizing for each division, as
necessary) would have been more expensive than building a SQL-Server
back-end, but it would have probably been more useful and profitable due to
greater individualization. The time it would have taken would have been more
than a year, and the training about the same. The SQL-Server solution
allowed more control by a central corporate entity, and made more sense in
that respect. It would have taken only about 6 weeks to build, but the
training would have taken the same amount of time as the other.
Unfortunately, the corporation had already invested millions in a J.D.
Edwards/PeopleSoft/Oracle solution, and were not interested in making the
change to SQL-Server. As a result, they got a piece of crap designed by
code-monkeys, who new nothing about the business, or good database design,
and which did far less and cost much more to maintain than either an
Access/JET or a SQL-Server solution. So much for IT decisions made on the
golf course.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

"Michel Posseth [MCP]" wrote in
message ...
Bill

I get your point ,,,


However i was refering to the business solution Arvin described as it
sounded that this needed the power of a full blown rdbms so see my
comment
in this context .


michel



"William Vaughn" wrote:

JET can indeed outperform SQL Server or Oracle or any full-blown DBMS. Of
course it can. It's far, far simpler. A text file can out perform JET.
Just
as a screwdriver takes less power to operate than a jackhammer but can it
cut through a foot of concrete? No but, it can be the right tool for the
job--as long as you don't ask too much of it and know how to use it.

I've seen good Access applications and good Access/JET developers and
I've
seen sloppy, ignorant, uninformed and inexperienced developers for every
type of data access paradigm. Customers often can't tell the difference
until it's too late and they have made a career commitment to the
consultant
or employee--then it's even harder to purge the old and move over to a
working solution.

I've also seen deadly serious SQL Server applications that should never
have
been allowed to run. Good and bad applications are a function of the
developer, the dba, the architect and the people that manage them--not
the
tools, engines and Visual Studio. The best tools in the world in
inexperienced hands can still build crap.

--
__________________________________________________ ________________________
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)
__________________________________________________ __________________________________________
"Michel Posseth [MCP]" wrote in message
...

Well does this tell how good your Access program is , or does this
tell
what it tells me, that the Developers that wrote this new system did
not
do there job right
Or do you really believe Access outperfoms MS SQL or Oracle ?

There are lots of people out there that call themselves Developer ,
Software engineer ,DBA`s ,,,,,,, but do not deserve there working
titles
i had once to explain to a Company`s SQL DBA what BCNF stands for , and
so
i have numerous examples that i encountered .

And yes a well designed ACCESS database, with a well designed ACCESS
GUI
may perfom bether as a poorly designed Oracle database with a
spaghetti
coded Visual studio application .

Michel



"Arvin Meyer [MVP]" schreef in bericht
...
And to rebuff the myth that Access can't handle more than a few users,
one of my systems had 53 users with up to 75 connections (i.e.
multiple
front-ends could be opened by a single user. The users included 36 on
the
LAN, 8 accessing remotely using an ASP front-end, and 9 with Terminal
Server connections. Again, no corruption and no performance issues.

This particular system has now been replaced with a PeopleSoft system
running Oracle, with numerous connection issues and down-time. It has
less than 3/4 of the functionality, takes more users to do the same
work,
and the performance is abysmal when compared to what it replaced. It
cost
millions to build and millions to maintain. I just love it when "real"
developers go to work. It validates my entire raison d'etre for being
a
database developer.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

"Ed Metcalfe" wrote in message
...

"Ed Metcalfe" wrote in message
...

"Spam Catcher" wrote in message
. 1...
If you're processing 100K rows, shouldn't that be a red flag that
you're
making access do something it's not designed to do?

No! I have developed, and continue to support, three systems in
which
there is a table of nearly three million records. To date I have had
no
corruption issues and no performance issues.

Ed Metcalfe.


And just to clarify, these are multi-user systems not single-user
systems.

Ed Metcalfe.









  #43  
Old February 4th, 2008, 02:32 PM posted to microsoft.public.access,microsoft.public.dotnet.framework.adonet,microsoft.public.dotnet.languages.vb
Norman Yuan[_4_]
external usenet poster
 
Posts: 51
Default Opening Access db via DAO in vb.net

Which is better,ADO.NET, ADO, or DAO? in many or most cases it depends on
the concrete situation, how the data is accesses/used, rather than the
technology the developer choose without fully familiar with all available
options. There is surely some situation, using purely DAO would get you the
best performance to the application. So, the question is, if you have to use
DAO, why take a round trip from .NET COM interop? Go with VB5/6 and make
things simpe and straighforward.


"Arvin Meyer [MVP]" wrote in message
...
"Norman Yuan" schreef in bericht
...
With all other replies being post, I am just wondering: why on the earth
do you need to use DAO in .NET?


"Michel Posseth [MCP]" wrote in message
...
Well after thoroughly thinking about this question , the answer seems

You don`t

:-)

Or maybe we are both missing something here


What you're missing is that it's not .NET that is using DAO as much as the
JET engine. And you can use ADO very successfully with the JET engine, but
is will be slower. Typically, that speed in a well designed database with
a well designed query is of little concern, becuase it is not likely that
you will be searching through more than 100K rows in JET, so a 1/2 second
doesn't mean much. But if you are looping through a recordset with 100K of
rows, it can mean a significant difference.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com



  #44  
Old February 4th, 2008, 04:43 PM posted to microsoft.public.access,microsoft.public.dotnet.framework.adonet,microsoft.public.dotnet.languages.vb
Paul Clement
external usenet poster
 
Posts: 1
Default Opening Access db via DAO in vb.net

On Sun, 03 Feb 2008 21:27:15 GMT, Spam Catcher wrote:

¤ "Arvin Meyer [MVP]" wrote in
¤ :
¤
¤ My clients which include Fortune 500 companies, Federal and local
¤ government, and numerous others will be quite surprised. Departmental
¤ and low user count applications are Access's forte. I do suspect that
¤ there are far more single user Access applications, but the number
¤ multi-user apps runs in the millions.
¤
¤ Yes, it "works", butmost developers are only using it because it is what
¤ they're comfortable with. But with all the limitations with Access such as
¤ the threat of DB corruption in a multi-user environment, why not use a real
¤ embedded DB like SQL Compact Edition?
¤
¤ Even Microsoft acknowledges that Access isn't intended to be a general
¤ purposes database engine - rather a personal DB:
¤
¤ http://www.microsoft.com/sql/edition...omparison.mspx
¤
¤ I just don't see the point of using Access anymore when there are better
¤ alternatives out there.

I think you need to define what you mean by "better". Better for what?

SQL CE has its own set of limitations so it's not always a viable candidate. It lacks any user
interface (from which to create ad-hoc reports or queries) and there is no concurrent multi-user
support.


Paul
~~~~
Microsoft MVP (Visual Basic)
  #45  
Old February 4th, 2008, 04:49 PM posted to microsoft.public.access,microsoft.public.dotnet.framework.adonet,microsoft.public.dotnet.languages.vb
Arvin Meyer [MVP]
external usenet poster
 
Posts: 4,231
Default Opening Access db via DAO in vb.net

"Norman Yuan" wrote in message
...
Which is better,ADO.NET, ADO, or DAO? in many or most cases it depends on
the concrete situation, how the data is accesses/used, rather than the
technology the developer choose without fully familiar with all available
options. There is surely some situation, using purely DAO would get you
the best performance to the application.


True

So, the question is, if you have to use DAO, why take a round trip from
.NET COM interop? Go with VB5/6 and make things simpe and straighforward.


Usually, the prudent path is to use the technology you are already working
with. Why would anyone who is building a .NET app which needs to get some
data from a JET database, go with VB5 or VB6? If I were building a small
utility, I might consider using VB6, but not if I were building a database
centric app of any kind. If it was a local app (i.e. run on a LAN), I'd use
an Access front-end, and if it were an Internet app, I'd use either asp, or
more likely the .NET framework.

The gist of this thread, before it got side-tracked is which technology to
use with JET. That is almost always DAO. Like-wise ADO, or ADO.NET is
usually used with SQL-Server depending upon the front-end.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com


  #46  
Old February 4th, 2008, 06:03 PM posted to microsoft.public.access,microsoft.public.dotnet.framework.adonet,microsoft.public.dotnet.languages.vb
William Vaughn
external usenet poster
 
Posts: 4
Default Opening Access db via DAO in vb.net

Ah, you can use the RDL-based ReportViewer with SQLCe as well as the VS
Query Builder tools to build queries.

--
__________________________________________________ ________________________
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)
__________________________________________________ __________________________________________
"Paul Clement" wrote in message
...
On Sun, 03 Feb 2008 21:27:15 GMT, Spam Catcher
wrote:

¤ "Arvin Meyer [MVP]" wrote in
¤ :
¤
¤ My clients which include Fortune 500 companies, Federal and local
¤ government, and numerous others will be quite surprised. Departmental
¤ and low user count applications are Access's forte. I do suspect that
¤ there are far more single user Access applications, but the number
¤ multi-user apps runs in the millions.
¤
¤ Yes, it "works", butmost developers are only using it because it is what
¤ they're comfortable with. But with all the limitations with Access such
as
¤ the threat of DB corruption in a multi-user environment, why not use a
real
¤ embedded DB like SQL Compact Edition?
¤
¤ Even Microsoft acknowledges that Access isn't intended to be a general
¤ purposes database engine - rather a personal DB:
¤
¤ http://www.microsoft.com/sql/edition...omparison.mspx
¤
¤ I just don't see the point of using Access anymore when there are better
¤ alternatives out there.

I think you need to define what you mean by "better". Better for what?

SQL CE has its own set of limitations so it's not always a viable
candidate. It lacks any user
interface (from which to create ad-hoc reports or queries) and there is no
concurrent multi-user
support.


Paul
~~~~
Microsoft MVP (Visual Basic)


  #47  
Old February 4th, 2008, 06:25 PM posted to microsoft.public.dotnet.framework.adonet,microsoft.public.dotnet.languages.vb,microsoft.public.access
Cor Ligthert[MVP]
external usenet poster
 
Posts: 12
Default Opening Access db via DAO in vb.net

Michel,

I don't think that we should bring the knowledge of any body involved in
this messagethread in discussion and the last who deserves that is Alvin.

He comes with real points, that we don't agree from our point of view is
maybe something else, however I am interested to be able to look at it from
his point of view.

Cor

  #48  
Old February 4th, 2008, 06:44 PM posted to microsoft.public.access,microsoft.public.dotnet.framework.adonet,microsoft.public.dotnet.languages.vb
Spam Catcher
external usenet poster
 
Posts: 6
Default Opening Access db via DAO in vb.net

"Arvin Meyer [MVP]" wrote in
:

I'm really sorry that you think that Access/JET is a single-user
database. You're obviously missing giving some of your users a fast,
easily maintainable solution.


Microsoft thinks so too! Have you read their recent whitepapers? :-)



--
(Do not e-mail)
  #49  
Old February 4th, 2008, 07:46 PM posted to microsoft.public.dotnet.framework.adonet,microsoft.public.dotnet.languages.vb,microsoft.public.access
Michel Posseth [MCP]
external usenet poster
 
Posts: 12
Default Opening Access db via DAO in vb.net



Well if anybody has read in my messages that i question anybody`s knowledge
well in that case my humble apolygees
this is and was never my intention .

For me this was just a welcome and sharp discussion , and indeed with Arvin
and Ed i do not share there opinion on certain things



Michel



"Cor Ligthert[MVP]" schreef in bericht
...
Michel,

I don't think that we should bring the knowledge of any body involved in
this messagethread in discussion and the last who deserves that is Alvin.

He comes with real points, that we don't agree from our point of view is
maybe something else, however I am interested to be able to look at it
from his point of view.

Cor



  #50  
Old February 5th, 2008, 12:33 PM posted to microsoft.public.access,microsoft.public.dotnet.framework.adonet,microsoft.public.dotnet.languages.vb
Arvin Meyer [MVP]
external usenet poster
 
Posts: 4,231
Default Opening Access db via DAO in vb.net

"Spam Catcher" wrote in message
. 1...
"Arvin Meyer [MVP]" wrote in
:

I'm really sorry that you think that Access/JET is a single-user
database. You're obviously missing giving some of your users a fast,
easily maintainable solution.


Microsoft thinks so too! Have you read their recent whitepapers? :-)


Microsoft thinks that a million rows and 4000 columns are reasonable limits
for spreadsheets too. Have you seen Excel 2007?
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 04:27 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.