ADP准备好迎接黄金时段？ [英] ADP Ready for Prime Time?

问题描述

前段时间我发了一条消息。使用带有SQL Server的ADP文件

end而不是带有链接表的MDB文件，认为ADP文件

不会有问题。我得到的输入是ADP只是

，如果不是更多，那就是问题; ADO远比DAO有限，

需要大量的解决方法;并且最好留下一个经验丰富的MDB文件，而不是转换为ADP。


有问题的数据库是我从某人那里继承的否则谁以不太理想的方式实现了一些东西，他自己将其从另一个应用程序中的现有数据库转换成了b $ b。数据库需要进行修改，我们正在寻求从头开始重建它，并附加

附加功能。所以现在的问题不是坚持使用经验丰富的多元化公积金（MDB），而不是新的ADP;但更确切地说，使用SQL Server后端，MDB或ADP文件工作会更好吗？


显然，如果我们选择MDB文件我们可以重用许多DAO例程，

。但主要关注的是性能：哪一个将b / b提供更好的性能，更好的数据访问，更少的奇怪异常，

等等。开发时间不是主要问题。


数据库目前部分依赖于DAO，部分依赖于存储的

程序。显然，更多地向存储过程移动会更好，

但是前面可能仍会有大量的代码

结束。


有任何想法。 MDB与ADP或与此相关的任何其他内容将是

赞赏。


谢谢，


Neil

解决方案

2005年1月18日星期二07:38:50 GMT，Neil Ginsberg < nr*@nrgconsult.com>写道：

前段时间我发布了一条消息。使用带有SQL Server的ADP文件结束而不是带有链接表的MDB文件，认为ADP文件不会有问题。我得到的输入是，ADP只是，如果不是更多，那就是问题; ADO远比DAO有限，需要大量的解决方法;并且使用经过调整的MDB文件比转换为ADP更好。

有问题的数据库是我从其他人那里继承的以一种不太理想的方式，他自己将其从另一个应用程序中的现有数据库转换为
。数据库需要进行改进，我们希望通过附加功能从头开始重建数据库。所以现在的问题不是坚持使用经验丰富的MDB而不是新的ADP;但是，哪个更适合使用SQL Server后端，MDB或ADP文件？

显然，如果我们使用MDB文件，我们可以重用许多DAO惯例，酌情。但这里主要关注的是性能：哪一个会提供更好的性能，更好的数据访问，更少的奇怪的异常，
等等。开发时间不是主要问题。


这不仅仅是开发时间，而是运行时间行为的不可预测性。使用ADP提供可验证的高质量代码（b
）要快得多。他们太过匆匆忙忙地修补了一片混合物。

kludges。 ADP和ADO还引入了至少与性能改进一样多的性能瓶颈，并且精心设计的MDB客户端/服务器应用程序已经表现得非常好。

数据库当前部分依赖于DAO，部分依赖于存储的
程序。显然，更多地转向存储过程会更好，
但前端可能仍会有大量代码。


这很明显，但不一定正确。使用绑定到链接表上的DAO记录集的
表单，Access可以很好地工作。如果你偏离了这一点，那么你可以完全废弃Access并在某些东西中实现自定义GUI

如C＃或Java - 当然，这可能是你最好的答案如果时间是

不是问题。


关于存储过程的性能普遍优于Access

查询链接表，事实并非如此。在大多数情况下，Access

查询在服务器端生成一个准备好的语句，其功能与存储过程相似。当服务器稍后再次看到相同的准备好的

语句签名时，它会意识到它可以使用相同的查询

计划它为之前的语句计算 - 就像存储一样程序

只是没有无法通过访问绑定表单更新的麻烦。

任何想法。 MDB与ADP或与此相关的任何其他内容都将受到赞赏。

MDB比使用MDB更容易获得更高的可靠性和良好的性能

ADP - 期间。如果时间不是问题，请完全废弃Access并在真实中写下手工优化代码。编程语言。

Steve Jorgensen写道：

这不仅仅是开发时间，而是$ b $的不可预测性b运行时行为。
[snip]使用
MDB比ADP期间更容易获得更高的可靠性和良好性能。

史蒂夫，


你在这里讨论的问题是什么？或者你能指点一下

链接，谈谈其中一些（如果他们已被广泛讨论过

）？我有一段时间没有在CDMA''罩子周围;我知道

有很多人争论，我同意他们的意见，

学习ADO，因为它是新的没有任何意义，但是我不记得了b $ b还记得很多关于ADP的说法更容易在运行时贬值，或者继续需要更多的开发

时间（学习ADO除外）。


这绝不是一个巨魔或挑战。我一直在研究一个

项目，该项目使用MS SQL Server后端和过去7个月的
的ADP前端，我遇到过很少有我没见过的东西

在MDB中。或者至少那是我的印象 - 也许我只是看到了

树木。


Jeremy

PS：我会告诉你我在

Access中见过的最酷的运行时错误。它只发生在a2k3中，并且只有一个特定的数据表 - 查看子表单。而且很少和不可预测。但是在我们的一个表单上有一个
，如果运气好的话，你可以通过抓住滚动条来调整其中一个

子表单。在运行时。我们有很多人使用数据库，我们从来没有得到任何人的报告

发现这个特殊的错误。但是当我看到它时，确实吓到了我。我想看到它！

2005年1月18日05:41:56 - 0800， al*****@yahoo.com 写道：

史蒂夫Jorgensen写道：

这不仅仅是开发时间，而是

运行时

行为的不可预测性。

[snip]

使用

MDB比使用

ADP更容易获得更高的可靠性和良好的性能 - 期间。

史蒂夫，

你在这里谈论的问题是什么？或者你能指点一下
链接，谈谈其中一些（如果他们已被广泛讨论过）？我有一段时间没有在CDMA''罩子周围;我知道
有很多人争论，我同意他们的看法，学习ADO，因为它是新的没有任何意义，但我不是>记得读到很多关于ADP的遗传更容易在运行时摔倒，或者继续需要更多的开发时间（除了学习ADO）。

这是绝不是巨魔或挑战。我一直致力于一个使用MS SQL Server后端和过去七个月的ADP前端的项目，而且我遇到了很少的东西，我没有''在MDB中看到了
。或者至少那是我的印象 - 也许我只是看到了树木。

好​​吧，首先，ADP有制作某些多表查询的习惯

uneditable。查询的第一个版本可能是可编辑的，但在查询本身随机和看似微不足道的变化之后或者在下一个
访问服务包或MDAC升级后，它会发生变化。再次变得无法使用，并且

调整过程重新开始。我终于明白了这一点

，我甚至不尝试在ADP中的绑定表单上使用多表查询。

要么，我使用组合框作为相关表格中数据的查找（呃是的，

，这将有助于提高性能），或者必须使用单独的表格来添加/编辑

这是更多为用户点击和工作麻烦以及更多重复

的表单设计元素。


另一方面，有一个错误应该被修复，但实际上

并不是有时子窗体或子报表中的ORDER BY子句导致

出错。要修复它，有必要从ORDER BY子句中的表达式中删除表名限定符。当然，查询构建器总是打开表格限定符，并且如果没有

一些挖掘，它就不会显而易见了。


在ADP中，每当你在

服务器端查询中做一些与众不同的事情时，ADP就会感到困惑。例如，在我的MDB中，有时

我想要一个引用

服务器上另一个数据库中的表的视图。我这样做，例如，把常用的表放在一个数据库中使用TRUNCATE LOG ON CHECKPOINT来保存

临时数据所以我的备份

主要不用填充无关的添加和删除临时数据。

当你尝试将ADP绑定到此时，它会变得非常混乱，因为ADO是足够聪明的，足以试图查看底层表格，但不够智能

在服务器上的另一个数据库中查看它们。


查看存储过程和视图背后的ADP也很难使用
执行在MDB中正常工作的事情，例如使用安全视图，其中

用户具有通过视图授予的权限，即他们没有表格

直接。如果你知道这个问题并且非常小心，你可以解决这个问题。

。这是ADP试图为你思考的类别，因此很难使用后端典型的规则执行。


我现在还不记得所有其他问题，但我记得还有几个

。

A while back I posted a message re. using an ADP file with a SQL Server back
end as opposed to MDB file with linked tables, thinking that the ADP file
would be less problematic. The input I got was that the ADP would be just
as, if not more, problematic; that ADO is far more limited than DAO,
requiring a lot of workarounds; and that it would be better to stay with a
seasoned MDB file than to switch to an ADP.

The database in question was inherited by me from someone else who
implemented things in a less than ideal way, and he, himself, converted it
from an existing database in another application. The database needs to be
revamped, and we are looking to rebuild it from the ground up with
additional functionality. So now the question is not staying with a seasoned
MDB as opposed to a new ADP; but, rather, which would be better for working
with a SQL Server back end, an MDB or ADP file?

Obviously if we go with an MDB file we can reuse many of the DAO routines,
as appropriate. But the main concern here is performance: which one will
provide the better performance, better data access, fewer strange anomalies,
and so on. Development time isn''t the main concern.

The database currently relies in part on DAO and in part on stored
procedures. Obviously moving more towards stored procedures would be better,
but there will probably still be a significant amount of code in the front
end.

Any thoughts re. MDB vs. ADP or anything else related to this would be
appreciated.

Thanks,

Neil

解决方案

On Tue, 18 Jan 2005 07:38:50 GMT, "Neil Ginsberg" <nr*@nrgconsult.com> wrote:

A while back I posted a message re. using an ADP file with a SQL Server back
end as opposed to MDB file with linked tables, thinking that the ADP file
would be less problematic. The input I got was that the ADP would be just
as, if not more, problematic; that ADO is far more limited than DAO,
requiring a lot of workarounds; and that it would be better to stay with a
seasoned MDB file than to switch to an ADP.

The database in question was inherited by me from someone else who
implemented things in a less than ideal way, and he, himself, converted it
from an existing database in another application. The database needs to be
revamped, and we are looking to rebuild it from the ground up with
additional functionality. So now the question is not staying with a seasoned
MDB as opposed to a new ADP; but, rather, which would be better for working
with a SQL Server back end, an MDB or ADP file?

Obviously if we go with an MDB file we can reuse many of the DAO routines,
as appropriate. But the main concern here is performance: which one will
provide the better performance, better data access, fewer strange anomalies,
and so on. Development time isn''t the main concern.
It''s not just the develompment time, it''s the unpredictability of runtime
behavior. It''s just fastly harder to deliver verifiably high quality code
with ADPs. They''re too much of a hodge podge of hastily patched together
kludges. ADPs and ADO also introduce at least as many performance bottlenecks
as performance improvments, and well-designed MDB client/server apps have been
known to perform really well.
The database currently relies in part on DAO and in part on stored
procedures. Obviously moving more towards stored procedures would be better,
but there will probably still be a significant amount of code in the front
end.
That''s obvious, but not necessarily correct. Access works quite well using
forms bound to DAO recordsets on linked tables. if you deviate from that, you
might as well scrap Access altogether and implement custom GUIs in something
like C# or Java - of course, that might really be your best answer if time is
not an issue.

With respect to stored procedures performing universally better than Access
queries of linked tables, it''s simply not the case. In most cases, an Access
query generates a prepared statement on the server side which functions much
like a stored procedure would. When the server sees the same prepared
statement signature again later on, it will realize it can use the same query
plan it computed for the statement previously - just like a stored procedurem
only without the headaches of being unable to update via an Access bound form.
Any thoughts re. MDB vs. ADP or anything else related to this would be
appreciated.

It''s easier to get higher reliability and good performance with an MDB than an
ADP - period. If time is not an issue, scrap Access altogether and write
hand-optimized code in a "real" programming language.

Steve Jorgensen wrote:

It''s not just the develompment time, it''s the unpredictability of runtime behavior. [snip] It''s easier to get higher reliability and good performance with an MDB than an ADP - period.

Steve,

What are the issues you''re talking about here? Or can you point me to a
link that talks about some of them (if they''ve been discussed
extensively)? I haven''t been around the CDMA ''hood for a while; I know
there are plenty of people who argue, and I agree with them, that
learning ADO because it''s new doesn''t make any sense, but I don''t
remember reading much that talks about ADPs being inherintly more prone
to falling over at run time, or inherintly requiring more development
time (other than learning ADO).

This is in no way a troll or a challenge. I''ve been working on a
project that uses a MS SQL Server back end and an ADP front for the
last seven months, and I''ve run into very few things that I hadn''t seen
in an MDB. Or at least that''s my impression--maybe I''m just seeing
trees, though.

Jeremy

PS: I will tell you about the coolest run-time bug I''ve ever seen in
Access, though. It only happened in a2k3, and only with one particular
datasheet-viewed subform. And only very rarely and unpredicatbly. But
on one of our forms, if you got lucky, you could resize one of the
subforms by grabbing the scroll bar. At run time. We have a lot of
people using the database, and we''ve never gotten a report of anyone
finding this particular bug. But it sure scared the heck outta me when
I saw it!

On 18 Jan 2005 05:41:56 -0800, al*****@yahoo.com wrote:

Steve Jorgensen wrote:

It''s not just the develompment time, it''s the unpredictability of

runtime

behavior.

[snip]

It''s easier to get higher reliability and good performance with an

MDB than an

ADP - period.

Steve,

What are the issues you''re talking about here? Or can you point me to a
link that talks about some of them (if they''ve been discussed
extensively)? I haven''t been around the CDMA ''hood for a while; I know
there are plenty of people who argue, and I agree with them, that
learning ADO because it''s new doesn''t make any sense, but I don''t
remember reading much that talks about ADPs being inherintly more prone
to falling over at run time, or inherintly requiring more development
time (other than learning ADO).

This is in no way a troll or a challenge. I''ve been working on a
project that uses a MS SQL Server back end and an ADP front for the
last seven months, and I''ve run into very few things that I hadn''t seen
in an MDB. Or at least that''s my impression--maybe I''m just seeing
trees, though.

Well, for one thing, ADPs have a habit of making certain multi-table queries
uneditable. The first version of a query may be editable, but after some
random and seemingly trivial change in the query itself or afger the next
Access service pack or MDAC upgrade, it becomes uneditable again, and the
tweaking process starts all over again. I''ve finally gotten to the point
where I don''t even try to use multi-table queries on bound forms in an ADP.
Either, I use combo boxes as lookups for data in related tables (uh yeah,
that''ll help performance), or have to use separate forms for adding/editing
which is more clicks and work hassle for the user as well as more duplication
of form design elements.

For another thing, there is a bug that was supposedly fixed, but actually
isn''t in which sometimes an ORDER BY clause in a subform or subreport causes
an error. To fix it, it is necessary to remove the table name qualifier from
the expression in the ORDER BY clause. Of course, the query builder always
puts the table qualifiers on, and it''s never obvious what''s broken without
some digging.

In ADPs, any time you do anything slightly out of the ordinary in a
server-side query, the ADP gets confused. For instance, in my MDBs, sometimes
I like to have a view that references a table in another database on the
server. I do this, for instance, to put tables frequently used to hold
temporary data in a database with TRUNCATE LOG ON CHECKPOINT so my backups
aren''t filled mostly with irrelevant adding and deleting of temporary data.
When you try to bind an ADP to this, it gets really confused beacause ADO is
smart enough to try to look at the underlying tables, but not smart enough to
look at them in another database on the server.

The ADP looking behind your stored procedures and views also makes it hard to
do things that work fine in an MDB such as using a view for security where the
user has permissions granted via the view that they don''t haveon the tables
directly. If you know the issue and are -very- careful, you can work around
this. This is in the category of ADPs trying to think for you and thus making
it very hard to use what should be typical rule enforcement on the back-end.

I can''t remember all the other issues right now, but I remember that there are
several more.

这篇关于ADP准备好迎接黄金时段？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！