哪里会注意到臃肿的负面影响？ [英] where will I notice negative side effects of bloat?
问题描述
关于这篇文章底部的问题....背景信息
紧接在下面。
访问97
SQL服务器2000
请注意：虽然主题行使用膨胀这个词，但这个
帖子不是我该怎么办？防止臃肿？查询。当我在这个小组中搜索有关臃肿的信息的时候，我想b / b
相信我对某些事情有了基本的了解
那个导致臃肿。我认识到我的应用程序正在做一些有助于膨胀的东西：它在会话开始时在
开始设置一个querydef，然后在<结尾处删除该querydef br />
会话。这个小组的帖子表明，随着时间的推移，
将导致臃肿，这似乎与我观察到的b
一致。
我的应用程序（报告系统）执行以下操作：
1）在会话开始时，设置querydef
）当用户请求报告时，应用程序设置querydef;
所有报告的所有信息都驻留在SQL Server
2000数据库中，所以querydef是pass-thru查询。 querydef的.SQL
属性是一个字符串，其内容是一个调用
到存储的proc
3）Access应用程序调用存储过程
4）存储过程返回结果集
5）Access应用程序获取结果集并将其用作
$ b一个Access报表对象的$ b记录源。
6）在会话结束时，应用程序''清理''，即它
删除它的querydef在
会话开始时建立
我认识到这会随着时间的推移而导致臃肿，也就是说，
$ b $事实上，与我观察到的一致。压缩时，
应用程序大约为8MB。随着时间的推移，它已经增长到20MB，然后我再次将它压缩了。我猜测如果我没有压缩它，那么
将继续累积超过20MB水平的膨胀。我知道以下事实：
a）应用程序永远不会添加/删除/修改任何
访问表中的记录
b）应用程序永远不会创建/删除临时表
因此，当人们查看8MB应用程序中的数据库窗口时，会看到
相同的对象当一个人看着20MB
应用程序中的数据库窗口时。
所以，最后，我的问题......他们的主题是''哪里会我注意到了坏的副作用
？
1）加载20MB臃肿的应用程序需要更长的时间才会加载
加载8MB压缩的应用程序？
2）在20MB应用程序中加载表格的时间是否比在8MB应用程序中加载相同表单需要更长的时间？
/>
3）在20MB应用程序中加载报告所需的时间比
加载相同的报告（与记录源的结果集相同）需要更长的时间
8MB应用程序？
4）据我所知，一个20MB的应用程序占据了一席之地在磁盘上有更多的空间，
但是有没有其他负面影响，有一个膨胀的应用程序？
5）一切都在膨胀的应用程序中运行较慢，或者是减速
（如果有，实际上是减速）只有在第一次加载应用程序
时才会发生？
谢谢你。
< mi ************ @ yahoo.comwrote in message
news：15 ********************************** @ t1g2000p ra.googlegroups.com ...
本帖底部的问题....背景信息
我的申请（报告系统）执行以下操作：
1）在会话开始时，当用户请求报告时设置querydef
2）应用程序设置querydef;
也许您只需将报表绑定到链接表并使用where子句传递参数
？无论如何，链接的odbc表应该以相同的速度运行。
（除非有多表连接）。
5）Access应用程序获取结果集并将其用作Access报表对象的
记录源。
您是否在报告打开事件中分配查询？ （不清楚你怎么做
以上）。请记住，在设计
模式下修改对象时会发生大多数膨胀，然后保存它们。所以，如果你修改报告，你想避免
这个。
6）在会话结束时，应用程序''清理''，即它
删除它在
会话开始时建立的querydef
其实为什么删除它？这只是创建一个漏洞，比如删除你的文件
硬盘然后需要进行碎片整理。只需将查询留在原位。
并且，只需在下次修改它。你通常可以通过这种方式减少膨胀。
a）应用程序永远不会添加/删除/修改任何
访问表中的记录
很好，但它是否打开任何对象，如表单，报表或查询设计
模式然后保存？
我建议你将应用程序作为mde运行（这样，代码就不会被b * b变成未编译的，并且你会减少膨胀的可能性。安装jet sp3服务包，并且sr2b更新到办公室是必须的。
这两个可以显着减少你的腹胀问题，在某些情况下接近
消除它们。
b）应用程序永远不会创建/删除临时表
它不仅仅是表格，而是你翻转到设计模式或修改的任何对象以及
save会导致膨胀。
所以，wh一看到8MB应用程序中的数据库窗口，就会看到与在20MB
应用程序中查看数据库窗口时相同的对象。
所以，最后，我的问题......他们的主题是''我会在哪里注意到
的不良副作用？'
1）加载20MB膨胀的应用程序需要更长时间才能加载8MB压缩应用程序吗？
大部分没有。 ms-access仅加载它使用的部分。所以，如果你有
有一个包含1条记录的表，或300,000条记录在其中，而你只需加载ms-access应用程序，那么整个表就是没有加载到
内存中。因此，加载时间访问应该是相同的。
2）在20MB应用程序中加载表单需要更长的时间吗？
在8MB应用程序中加载相同的表单？
再次，不。我想也许在很长一段时间内它可能会减慢
位，但在大多数情况下，加载时间应保持相当稳定。
3）在20MB应用程序中加载报告所需的时间比在
加载相同的报告（与记录源具有相同的结果集）相同>
8MB的应用程序？
再次......不，不应该。
4）我明白20MB臃肿应用程序在磁盘上占用更多空间，
但是有一个膨胀的应用程序的其他负面影响？
是的，你大大增加了腐败的可能性，因为现在访问应用程序中的对象必须是
1000'保持。它非常像在高峰时段的交通中驾驶，因为你处理更多的汽车（或者我们的案例对象），你的机会增加了很多。你可以用一个用户运行一个applcation 5年，但如果你有5个用户运行
它，那么你有5倍的问题机会。因此，一张价值1亿美元的赌桌有更多的机会被击败，然后是一张2 / $
reocrds的牌桌。它对可能性和机会提出了质疑。因此，更多的东西和更多的膨胀
意味着系统在对象数量方面的压力更大。
5）做一切在一个臃肿的应用程序中运行速度较慢，或者是缓慢下降
（如果有，实际上是减速）只有在首次加载应用程序
时才会发生？
嗯它不应该，但它可能会少量。 （一般不会太多
注意到了）。将会有更多的对象。在应用程序中处理，但是
访问确实很好地忽略了那些额外的东西（而且，我们现在还没有真正处理b $ b处理这些天）。
确保代码不会编译的一种方法是使用mde。并且，mde'的运行速度也要快〜
。请注意，mde的一个很好的副作用是
未处理的代码错误不会破坏本地甚至全局变量（你的
应用程序只是保持清除沿）。所以，mde'倾向于使你的
应用程序更可靠。
和其他任何东西一样，如果你不改变汽车里的油，它不会爆炸，但最终不妨采用某种类型的维护
时间表的汽车，或者在他的情况下定期压缩前端。我b $ b有一些客户可以使用6个月，但是我再次注意不要
有任何臃肿......通常会在之前发布新的更新a
紧凑/修理无论如何都需要。
-
Albert D. Kallal（访问MVP）
加拿大艾伯塔省埃德蒙顿
pl ********** *******@msn.com
Access应用程序获取结果集并将其用作
Access报表对象的记录源。
请告诉我们你的Access 97应用程序是如何做到这一点的。要么我老了
又愚蠢或者你已经完成了不可能的事情。 （好吧......也许全部
三！）
您是否测试了您的申请，省略或评论了
程序你相信导致观察到的膨胀？你可以验证
这样做没有膨胀吗？
至于你对速度的问题，我几乎可以肯定是正确的
每个答案都是可能！。 Access的运作非常神秘。
BTW，ADP非常小而且TTBOMK，不会臃肿。
mi ************ @ yahoo.com 在新闻中写道：155f6bdf-8194-4760-8a46-
10**********@t1g2000pra.googlegroups.com ：
对这篇文章底部的问题....背景信息
紧接在下面。
访问97
SQL Server 2000
帖子不是我能做些什么来预防臃肿？查询。当我在这个小组中搜索有关臃肿的信息的时候，我想b / b
相信我对某些事情有了基本的了解
那个导致臃肿。我认识到我的应用程序正在做一些有助于膨胀的东西：它在会话开始时在
开始设置一个querydef，然后在<结尾处删除该querydef br />
会话。这个小组的帖子表明，随着时间的推移，
将导致臃肿，这似乎与我观察到的b
一致。
我的应用程序（报告系统）执行以下操作：
1）在会话开始时，设置querydef
）当用户请求报告时，应用程序设置querydef;
所有报告的所有信息都驻留在SQL Server
2000数据库中，所以querydef是pass-thru查询。 querydef的.SQL
属性是一个字符串，其内容是一个调用
到存储的proc
3）Access应用程序调用存储过程
4）存储过程返回结果集
5）Access应用程序获取结果集并将其用作
$ b一个Access报表对象的$ b记录源。
6）在会话结束时，应用程序''清理''，即它
删除它的querydef在
会话开始时建立
我认识到这会随着时间的推移而导致臃肿，也就是说，
$ b $事实上，与我观察到的一致。压缩时，
应用程序大约为8MB。随着时间的推移，它已经增长到20MB，然后我再次将它压缩了。我猜测如果我没有压缩它，那么
将继续累积超过20MB水平的膨胀。我知道以下事实：
a）应用程序永远不会添加/删除/修改任何
访问表中的记录
b）应用程序永远不会创建/删除临时表
因此，当人们查看8MB应用程序中的数据库窗口时，会看到
相同的对象当一个人看着20MB
应用程序中的数据库窗口时。
所以，最后，我的问题......他们的主题是''哪里会我注意到了坏的副作用
？
1）加载20MB臃肿的应用程序需要更长的时间才会加载
加载8MB压缩的应用程序？
2）在20MB应用程序中加载表格的时间是否比在8MB应用程序中加载相同表单需要更长的时间？
/>
3）在20MB应用程序中加载报告所需的时间比
加载相同的报告（与记录源的结果集相同）需要更长的时间
8MB应用程序？
4）据我所知，一个20MB的应用程序占用了在磁盘上有更多的空间，
但是有没有其他负面影响使用臃肿的应用程序？
5）在膨胀的应用程序中，一切都运行得慢，还是慢只有在首次加载应用程序
时才发生
（如果有，实际上是减速）？
谢谢。
8月8日，11：23 * pm，lyle fairfield< lylef ... @ yah00.cawrote：
< blockquote class =post_quotes>
请告诉我们你的Access 97应用程序如何做到这一点。要么我老了
又愚蠢或者你已经完成了不可能的事情。 （好吧......也许全部
三！）
我的预感是我在描述结果集/记录源方面做得不好
关系在我的原帖中......我在我的
原帖中使用了以下措辞：
" Access application接受结果集并将其用作Access报表对象的
记录源。
这是我所指的代码：
<在报告对象的公开事件中，所以我。是指
报表对象>
Dim qdf作为QueryDef
Dim strConnect as String
strConnect =" ODBC;" &安培; _
" DRIVER = SQL Server;" &安培; _
" SERVER = DummyServer;" &安培; _
" UID = DummyUserid;" &安培; _
" DATABASE = DummyDB;" &安培; _
" Trusted_Connection = Yes;" &安培; _
" Network = DBMSSOCN"
''建立一个名为qryDummy的querydef;
设置qdf = CurrentDB.CreateQueryDef（ " qryDummy"，" Select * FROM
tblDummy"）
qdf.Connect = strConnect
qdf.ODBCTimeout = 60
''uspDummy是SQL Server 2000上存储过程的名称
数据库
qdf.SQL =" EXEC uspDummy"
''将此报表对象的记录源设置为
querydef的名称;
''提醒：此代码处于公开状态报告对象的事件;我在调试模式中观察了
''
报告中的最后一个语句之后的某个时间打开
''并且在报告中的第一个声明激活事件之前，MS
访问将：
''a）运行存储的proc uspDummy
''b）从存储过程中获取结果集并在报告中填充
控件
''（
$ b $的ControlSource属性） b控件对应
''与存储的返回结果集中的列名
proc）
Me.RecordSource =" qryDummy"
<代码片段结束>
所以，这就是我的意思......用它作为记录来源
访问报告对象
Question toward the bottom of this post....background information
immediately below.
Access 97
SQL Server 2000
Please note: although the subject line uses the word ''bloat'', this
post is NOT a "what can I do to prevent bloat?" inquiry. When I
searched the postings in this group for information about bloat, I
believe I gained a rudimentary understanding of some of the things
that contribute to bloat. I recognize that my application is doing
something that contributes to bloat: it sets up a querydef at the
beginning of a session and then deletes that querydef at the end of
the session. The posts in this group suggest that over time, that
will cause bloat, and that seems to be consistent with what I''ve
observed.
My application (a reporting system) does the following:
1) at the beginning of a session, sets up a querydef
2) when a user requests a report the application sets up the querydef;
all of the information for all of the reports reside on a SQL Server
2000 database, so the querydef is a pass-thru query. The .SQL
property of the querydef is a string, the contents of which is a call
to a stored proc
3) the Access application calls the stored proc
4) the stored proc returns a result set
5) the Access application takes the result set and uses it as the
recordsource for an Access report object.
6) at the end of the session, the application ''cleans up'', i.e. it
deletes the querydef that it established at the beginning of the
session
I recognize that this will, over time cause bloat, and that is, in
fact, consistent with with I''ve observed. When compacted the
application is about 8MB. Over time, it has grown to 20MB before I''ve
compacted it again. I''m guessing that if I hadn''t compacted it, it
would have continued to accumulate bloat beyond the 20MB level. I
know for a fact that:
a) the application never adds/deletes/modifies records in any of the
Access tables
b) the application never creates/deletes temp tables
So, when one looks at the database window in the 8MB app, one sees the
same objects as when one looks at the database window in the 20MB
app.
So, finally, my questions...they have a theme of ''where will I notice
the bad side effects?"
1) will it take longer to load the 20MB bloated app than it will to
load the 8MB compacted app?
2) will it take longer to a load form in the 20MB app than it will to
load the same form in the 8MB app?
3) will it take longer to load a report in the 20MB app than it will
to load the same report (with the same result set as recordsource) in
the 8MB app?
4) I understand that a 20MB bloated app occupies more space on disk,
but are there other negative side effects of having a bloated app?
5) Does everything run slower in a bloated app, or is the slow down
(if there is, in fact, a slow down) happen only when the application
is first loaded?
Thank you.
<mi************@yahoo.comwrote in message
news:15**********************************@t1g2000p ra.googlegroups.com...Question toward the bottom of this post....background information
My application (a reporting system) does the following:
1) at the beginning of a session, sets up a querydef
2) when a user requests a report the application sets up the querydef;Perhaps you just bind the report to a linked table and pass the parameters
using a where clause? A linked odbc table should run about as fast anyway.
(unless there is multi-table joins).
5) the Access application takes the result set and uses it as the
recordsource for an Access report object.Are you assigning query in the reports open event? (not clear how you doing
the above). Remember most bloat occurs when you modify objects in design
mode and then save them. So, if your modifying the report, you want to avoid
this.
6) at the end of the session, the application ''cleans up'', i.e. it
deletes the querydef that it established at the beginning of the
sessionActually why delete it? That just creates a hole like deleting a file on you
hard disk that then needs defragmenting. Simply leave the query in place.
And, just modify it for next time. You can often reduce bloat this way.
a) the application never adds/deletes/modifies records in any of the
Access tablesFine, but does it open any object like a form, or report, or query in design
mode and then save it?
I would suggest you run the application as a mde (that way, code can''t
become un-compiled, and you reduce chances of bloat that way. it is a MUST
to install the jet sp3 serviced pack, and the sr2b update to office. Both of
these can significantly reduce your bloating problems, and in some case near
eliminate them.
b) the application never creates/deletes temp tablesIt not just tables, but any object you flip into design mode or modify and
save will cause bloat.
So, when one looks at the database window in the 8MB app, one sees the
same objects as when one looks at the database window in the 20MB
app.
So, finally, my questions...they have a theme of ''where will I notice
the bad side effects?"
1) will it take longer to load the 20MB bloated app than it will to
load the 8MB compacted app?For the most part no. ms-access only loads the parts it using. So, if you
have a table with 1 record in it, or 300,000 records it in it , and you
simply load the ms-access application, that whole table is NOT loaded into
memory. So, thus the load time access is should be the same.
2) will it take longer to a load form in the 20MB app than it will to
load the same form in the 8MB app?Again, no. I suppose perhaps over a LONG period of time it might slow down a
bit, but for the most part the load time should remain fairly constant.
3) will it take longer to load a report in the 20MB app than it will
to load the same report (with the same result set as recordsource) in
the 8MB app?Once again...no it should not.
4) I understand that a 20MB bloated app occupies more space on disk,
but are there other negative side effects of having a bloated app?Yes, you substantially increase the chances of corruption as now there are
1000''s of objects in the access application that must be maintained. It much
like driving in rush hour traffic, you much increase your chances of a
accident since your dealing with more cars (or in our case objects). You can
run an applcation with 1 user for 5 years, but if you have 5 users running
it, then you have 5 times the chance of a problem. So, a table with 1
million reocrds has more chances of being damanged then a table with 2
reocrds. It quesiton of probablbiy and chance. So, more stuff and more bloat
means that the system is stressed more in terms of the number of objects.
5) Does everything run slower in a bloated app, or is the slow down
(if there is, in fact, a slow down) happen only when the application
is first loaded?Well it should not, but it likely does a small amount. (generally not be too
noticed). There will be more "objects" to deal with in the application, but
access does a very good job of ignoring that extra stuff (and, we not really
processing bound these days).
One way to ensure code does not un-compile is to use a mde. And, mde''s tend
to run a bit faster also. Note that a great side effect of a mde is that
un-handled code errors don''t blow out local, or even global variables (your
application just keeps chucking along). So, mde''s tend to make your
application more reliable.
Like anything else, if you don''t change the oil in your car, it will not
blow up, but eventually it good idea to adopt some type of maintains
schedule for tat car, or in his case regular compacting of the front end. I
have some clients that go for 6 months, but then again I taken care to not
have any bloat...and usually a new update is issued to them before a
compact/repair is needed anyway.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
the Access application takes the result set and uses it as therecordsource for an Access report object.Please, tell us how your Access 97 application does this. Either I am old
and stupid or you have accomplished the impossible. (OK ... maybe all
three!)
Have you tested your application omitting or commenting out the
procedures which you believe cause the observed bloat? Can you verify
that there is no bloat when this is done?
As to your questions about speed, I am almost certain that the correct
answer to each is, "Maybe!". The workings of Access are quite mysterious.
BTW, ADPs are wonderfully small and TTBOMK, do not bloat.
mi************@yahoo.com wrote in news:155f6bdf-8194-4760-8a46-
10**********@t1g2000pra.googlegroups.com:
Question toward the bottom of this post....background information
immediately below.
Access 97
SQL Server 2000
Please note: although the subject line uses the word ''bloat'', this
post is NOT a "what can I do to prevent bloat?" inquiry. When I
searched the postings in this group for information about bloat, I
believe I gained a rudimentary understanding of some of the things
that contribute to bloat. I recognize that my application is doing
something that contributes to bloat: it sets up a querydef at the
beginning of a session and then deletes that querydef at the end of
the session. The posts in this group suggest that over time, that
will cause bloat, and that seems to be consistent with what I''ve
observed.
My application (a reporting system) does the following:
1) at the beginning of a session, sets up a querydef
2) when a user requests a report the application sets up the querydef;
all of the information for all of the reports reside on a SQL Server
2000 database, so the querydef is a pass-thru query. The .SQL
property of the querydef is a string, the contents of which is a call
to a stored proc
3) the Access application calls the stored proc
4) the stored proc returns a result set
5) the Access application takes the result set and uses it as the
recordsource for an Access report object.
6) at the end of the session, the application ''cleans up'', i.e. it
deletes the querydef that it established at the beginning of the
session
I recognize that this will, over time cause bloat, and that is, in
fact, consistent with with I''ve observed. When compacted the
application is about 8MB. Over time, it has grown to 20MB before I''ve
compacted it again. I''m guessing that if I hadn''t compacted it, it
would have continued to accumulate bloat beyond the 20MB level. I
know for a fact that:
a) the application never adds/deletes/modifies records in any of the
Access tables
b) the application never creates/deletes temp tables
So, when one looks at the database window in the 8MB app, one sees the
same objects as when one looks at the database window in the 20MB
app.
So, finally, my questions...they have a theme of ''where will I notice
the bad side effects?"
1) will it take longer to load the 20MB bloated app than it will to
load the 8MB compacted app?
2) will it take longer to a load form in the 20MB app than it will to
load the same form in the 8MB app?
3) will it take longer to load a report in the 20MB app than it will
to load the same report (with the same result set as recordsource) in
the 8MB app?
4) I understand that a 20MB bloated app occupies more space on disk,
but are there other negative side effects of having a bloated app?
5) Does everything run slower in a bloated app, or is the slow down
(if there is, in fact, a slow down) happen only when the application
is first loaded?
Thank you.
On Aug 8, 11:23*pm, lyle fairfield <lylef...@yah00.cawrote:
Please, tell us how your Access 97 application does this. Either I am old
and stupid or you have accomplished the impossible. (OK ... maybe all
three!)My hunch is that I did a bad job of describing result-set/recordsource
relationship in my original post...I used the following wording in my
original post:
"the Access application takes the result set and uses it as the
recordsource for an Access report object."
Here is the code to which I was referring:
<in the open event of the report object , so "Me." refers to the
report object>
Dim qdf As QueryDef
Dim strConnect as String
strConnect = "ODBC;" & _
"DRIVER=SQL Server;" & _
"SERVER=DummyServer;" & _
"UID=DummyUserid;" & _
"DATABASE=DummyDB;" & _
"Trusted_Connection=Yes;" & _
"Network=DBMSSOCN"
'' establish a querydef named qryDummy;
Set qdf = CurrentDB.CreateQueryDef("qryDummy", "Select * FROM
tblDummy")
qdf.Connect = strConnect
qdf.ODBCTimeout = 60
'' uspDummy is the name of a stored proc on the SQL Server 2000
database
qdf.SQL = "EXEC uspDummy"
'' set the recordsource of this report object to the name of the
querydef;
'' reminder: this code is in the open event of the report object; I
have observed
'' in debug mode that sometime after the last statement in the
report open
'' and before the first statement in the report activate event, MS
Access will:
'' a) run the stored proc uspDummy
'' b) take the result set from that stored proc and populate the
controls
'' in the report (the ControlSource properties of the
controls correspond
'' with the column names in the result set returned by stored
proc)
Me.RecordSource = "qryDummy"
<end of code snippet>
So, that''s what I meant by "...uses it as the recordsource for an
Access report object"
这篇关于哪里会注意到臃肿的负面影响？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
