A
Arvin Meyer [MVP]
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.
how to get at the data in a JET database using .NET.
A
Arvin Meyer [MVP]
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
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
N
Norman Yuan
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.
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.
P
Paul Clement
¤ ¤
¤ > 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/editions/compact/sscecomparison.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)
¤ > 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/editions/compact/sscecomparison.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)
A
Arvin Meyer [MVP]
Norman Yuan said:
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.
W
William Vaughn
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)
____________________________________________________________________________________________
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)
____________________________________________________________________________________________
C
Cor Ligthert[MVP]
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
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
G
Guest
Microsoft thinks so too! Have you read their recent whitepapers?
M
Michel Posseth [MCP]
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
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
A
Arvin Meyer [MVP]
Spam Catcher said: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?
W
William Vaughn
I don't expect they do, but their customers seem to think that's necessary.
--
__________________________________________________________________________
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)
____________________________________________________________________________________________
--
__________________________________________________________________________
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)
____________________________________________________________________________________________
L
Larry Linson
William Vaughn said:
I know: The customer isn't always right, but, if the bills get paid, it's
the customer who pays them.
Even so, with the Mighty Microsoft Marketing Machine's golden tongues and
the Mighty Microsoft Development and Support Machine's golden abilities, it
would seem that Microsoft could have educated their customers instead of
giving them a large coil of rope with which to hang themselves.
I'm surprised, Bill, to hear this from someone who's sufficiently concerned
about the quite stable, proven, and eminently usable Jet database engine
that he thinks Microsoft ought to abandon it (for which read: take it away
from their customers) and replace it with SQL Server. (I would hope you also
think that they need to improve SQL Server <whatever edition> so that, to
the end-user, it is equally as seamless to use as is Jet.)
Larry Linson
Microsoft Office Access MVP
M
Mary Chipman [MSFT]
Arvin makes some excellent points that are often lost on internal
folks at msft, especially the SQLS team.
Bear in mind that each product team produces its own whitepapers in
the hopes that providing detailed information about their product will
not only help customers create successful solutions, but also increase
the revenue stream for their product. Consciously or unconsciously,
bias often creeps in, and in the case of the long-running Access/SQL
feud, there has been a tendency to showcase the failure cases when
Access was used inappropriately while ignoring the silent evidence of
its spectacular success in creating real-world applications with a low
TCO.
So when reading whitepapers, it helps to keep an open mind and
consider the source. The following paper was written by the president
of FMS (an ISV creating Access/SQLS tools) and vetted by a member of
the SQL Server team:
Microsoft Access or SQL Server 2005: What's Right in Your
Organization?
http://www.microsoft.com/sql/solutions/migration/access/sql-or-access.mspx
This one was written by an MVP and vetted by both the Access and SQL
Server teams:
Optimizing Microsoft Office Access Applications Linked to SQL Server
http://msdn2.microsoft.com/en-us/library/bb188204.aspx
Hope this helps shed some light on the subject while damping down the
heat
--Mary
folks at msft, especially the SQLS team.
Bear in mind that each product team produces its own whitepapers in
the hopes that providing detailed information about their product will
not only help customers create successful solutions, but also increase
the revenue stream for their product. Consciously or unconsciously,
bias often creeps in, and in the case of the long-running Access/SQL
feud, there has been a tendency to showcase the failure cases when
Access was used inappropriately while ignoring the silent evidence of
its spectacular success in creating real-world applications with a low
TCO.
So when reading whitepapers, it helps to keep an open mind and
consider the source. The following paper was written by the president
of FMS (an ISV creating Access/SQLS tools) and vetted by a member of
the SQL Server team:
Microsoft Access or SQL Server 2005: What's Right in Your
Organization?
http://www.microsoft.com/sql/solutions/migration/access/sql-or-access.mspx
This one was written by an MVP and vetted by both the Access and SQL
Server teams:
Optimizing Microsoft Office Access Applications Linked to SQL Server
http://msdn2.microsoft.com/en-us/library/bb188204.aspx
Hope this helps shed some light on the subject while damping down the
heat
--Mary
J
John
To run synchronising on the backend db which is a replicated access database