紧凑的有趣问题。有什么想法消除？ [英] Interesting issue with compaction. Any ideas to eliminate?

问题描述

我偶然发现了一个有趣的问题，关于压缩

一个访问前端数据库，它驻留在一个DFS目标上，该目标利用

FRS镜像共享点，以及我想知道是否有人知道克服它的方式

。


对于那些不了解DFS或FRS的人，DFS代表分布式

文件系统，基本上涉及安装各个共享点

驻留在一个特殊共享点下面的各种计算机上。当您访问DFS共享下的已安装目录时，您无形地将

重定向到共享的真实位置。 FRS代表File

复制系统（我想。它可能是Service，tho）。如果你
表明DFS共享中的特定挂载点有两个或更多

目标共享点，你可以告诉Windows使用FRS来确保更改

将sharepoint中的文件复制到其他目标。

这两种都是Windows 2003服务器的内置技术。


开我所观察到的。我们有一个前端/后端Access 2003

数据库应用程序驻留在其中一个FRS复制的

共享点上，并且可以选择在关闭时压缩数据库

开启了。我所看到的是，当压缩发生时，

前端数据库被重命名为DB1.mdb，然后这个名称更改将被复制到其他服务器。该名称永远不会再被更改，

留下用户用来访问数据库的快捷方式。

我已关闭紧凑选项上的紧凑，以及效果停止，

因此问题与FRS复制的共享点上的压缩相关联。我希望
能够重新打开压缩，因为数据库往往会增长相当大，但我不希望数据库的文件名发生变化。 br />
有什么想法吗？

I have stumbled upon an interesting issue with regard to compaction of
an access frontend database which resides on a DFS target that utilizes
FRS to mirror the sharepoint, and I was wondering if anyone knows a way
to overcome it.

For those who are unaware of DFS or FRS, DFS stands for Distributed
File System, and basically involves "mounting" various sharepoints that
reside on various computers underneath one special sharepoint. When
you access the mounted directory under the DFS share, you are invisibly
redirected to where the share really is. FRS stands for File
Replication System (I think. it could be Service, tho). If you
indicate that a particular mount point in the DFS share has two or more
target sharepoints, you can tell Windows to use FRS to ensure changes
to the files in the sharepoint are replicated to the other targets.
Both of these are built-in technologies of Windows 2003 server.

On to what I have observed. We have a frontend/backend Access 2003
database application residing on one of these FRS replicated
sharepoints, and have the option to compact the database on close
turned on. What I am seeing is that when the compaction occurs, the
frontend database is renamed to DB1.mdb, and this name change is then
replicated to the other servers. The name is never changed back again,
leaving the shortcuts that the users use to access the database broken.
I have turned off the compact on close option, and the effect stops,
so the issue is linked to compacting on a FRS replicated sharepoint. I
would like to turn the compaction back on, as the database tends to
grow rather large, but I do not want the database''s filename to change.
Any ideas?

推荐答案

da ******** @ gmail.com 写道：

我偶然发现了一个关于压缩的有趣问题
一个访问前端数据库，它驻留在一个DFS目标上，该目标利用FRS来镜像共享点，我想知道是否有人知道如何克服它。

对于那些谁不知道DFS或FRS，DFS代表分布式文件系统，并且基本上涉及安装。驻留在一个特殊共享点下的各种计算机上的各种共享点。
当您访问DFS共享下的已安装目录时，您将被无形地重定向到共享的真实位置。 FRS代表文件复制系统（我认为。它可能是Service，tho）。如果您指示DFS共享中的特定挂载点具有两个或更多目标共享点，则可以告诉Windows使用FRS来确保将sharepoint中的文件更改复制到其他
目标。这些都是Windows 2003
服务器的内置技术。

关于我观察到的内容。我们有一个前端/后端Access 2003
数据库应用程序驻留在这些FRS复制的共享点之一上，并且可以选择在关闭
打开时压缩数据库。我所看到的是，当压缩发生时，
前端数据库被重命名为DB1.mdb，然后将此名称更改复制到其他服务器。该名称永远不会再次更改
，留下用户用来访问数据库的快捷方式。我关闭了关闭选项的紧凑，并且
效果停止，因此问题与FRS
复制的sharepoint上的压缩有关。我想重新打开压缩，因为数据库往往会变得相当大，但我不希望更改
数据库的文件名。任何想法？

I have stumbled upon an interesting issue with regard to compaction of
an access frontend database which resides on a DFS target that
utilizes FRS to mirror the sharepoint, and I was wondering if anyone
knows a way to overcome it.

For those who are unaware of DFS or FRS, DFS stands for Distributed
File System, and basically involves "mounting" various sharepoints
that reside on various computers underneath one special sharepoint.
When you access the mounted directory under the DFS share, you are
invisibly redirected to where the share really is. FRS stands for
File Replication System (I think. it could be Service, tho). If you
indicate that a particular mount point in the DFS share has two or
more target sharepoints, you can tell Windows to use FRS to ensure
changes to the files in the sharepoint are replicated to the other
targets. Both of these are built-in technologies of Windows 2003
server.

On to what I have observed. We have a frontend/backend Access 2003
database application residing on one of these FRS replicated
sharepoints, and have the option to compact the database on close
turned on. What I am seeing is that when the compaction occurs, the
frontend database is renamed to DB1.mdb, and this name change is then
replicated to the other servers. The name is never changed back
again, leaving the shortcuts that the users use to access the
database broken. I have turned off the compact on close option, and
the effect stops, so the issue is linked to compacting on a FRS
replicated sharepoint. I would like to turn the compaction back on,
as the database tends to grow rather large, but I do not want the
database''s filename to change. Any ideas?

只是一个意见。永远不应允许多个用户打开单个

共享文件，因为这会导致频繁的损坏并降低性能。

推荐的方法是将您的应用拆分为共享的;仅数据文件

和前端文件的单独本地副本。为每个用户。使用这个

方法Compact On Close因为它只会压缩前端文件，这意味着你又回到了对数据文件进行常规手动和/或
压缩，而你的原始问题变得毫无意义。 br />

-

我没有查看附加的电子邮件帐户

到此消息。发送给... ...

在Hunter dot com的RBrandt

Just an opinion. One should never allow multiple users to open a single
shared file as this leads to frequent corruptions and degrades performance.
The recommended approach is to split your app into a shared "data only" file
and individual local copies of a "front end file" for each user. With this
approach "Compact On Close" is rendered pretty useless as it only compacts
the front end file meaning that you are back to doing regular manual
compactions on the data file and your original issue becomes moot.

--
I don''t check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

我认为原因是Access重命名当前副本，然后

将其压缩成具有旧名称的文件，最后删除重命名的

原始文件。我无法想象这个问题的解决方法是什么。


2005年7月19日07:13:47 -0700，da ***** ***@gmail.com" < da ******** @ gmail.com>

写道：

I believe the cause of this is that Access renames the current copy, then
compacts it into a file with the old name, and finally deletes the renamed
original. I can''t think of what a work-around might be for this problem.

On 19 Jul 2005 07:13:47 -0700, "da********@gmail.com" <da********@gmail.com>
wrote:

我偶然发现了一个关于压实的有趣问题
一个访问前端数据库，它驻留在一个利用FRS镜像共享点的DFS目标上，我想知道是否有人知道克服它的方法。
对于那些不了解DFS或FRS的人，DFS代表分布式文件系统，基本上涉及安装。各种共享点位于一个特殊共享点下的各种计算机上。当您访问DFS共享下的已安装目录时，您将被无形地重定向到共享的真实位置。 FRS代表File
复制系统（我认为。它可能是Service，tho）。如果您指示DFS共享中的特定挂载点具有两个或更多目标共享点，则可以告诉Windows使用FRS来确保将sharepoint中的文件的更改复制到其他目标。
这两个都是Windows 2003服务器的内置技术。

我所观察到的。我们有一个前端/后端Access 2003
数据库应用程序驻留在这些FRS复制的共享点之一上，并且可以选择在关闭
打开时压缩数据库。我所看到的是，当压缩发生时，
前端数据库被重命名为DB1.mdb，然后将此名称更改复制到其他服务器。该名称永远不会再被更改，
保留用户用来访问数据库的快捷方式。
我关闭了紧凑的选项，效果停止了，
所以问题与FRS复制的共享点上的压缩相关联。我希望重新打开压缩，因为数据库往往会变得相当大，但我不希望数据库的文件名发生变化。
任何想法？

I have stumbled upon an interesting issue with regard to compaction of
an access frontend database which resides on a DFS target that utilizes
FRS to mirror the sharepoint, and I was wondering if anyone knows a way
to overcome it.

For those who are unaware of DFS or FRS, DFS stands for Distributed
File System, and basically involves "mounting" various sharepoints that
reside on various computers underneath one special sharepoint. When
you access the mounted directory under the DFS share, you are invisibly
redirected to where the share really is. FRS stands for File
Replication System (I think. it could be Service, tho). If you
indicate that a particular mount point in the DFS share has two or more
target sharepoints, you can tell Windows to use FRS to ensure changes
to the files in the sharepoint are replicated to the other targets.
Both of these are built-in technologies of Windows 2003 server.

On to what I have observed. We have a frontend/backend Access 2003
database application residing on one of these FRS replicated
sharepoints, and have the option to compact the database on close
turned on. What I am seeing is that when the compaction occurs, the
frontend database is renamed to DB1.mdb, and this name change is then
replicated to the other servers. The name is never changed back again,
leaving the shortcuts that the users use to access the database broken.
I have turned off the compact on close option, and the effect stops,
so the issue is linked to compacting on a FRS replicated sharepoint. I
would like to turn the compaction back on, as the database tends to
grow rather large, but I do not want the database''s filename to change.
Any ideas?

Steve Jorgensen写道：

Steve Jorgensen wrote:

我相信原因这是Access重命名当前副本，然后将其压缩成具有旧名称的文件，最后删除重命名的
原始文件。我无法想象这个问题的解决方法是什么。

I believe the cause of this is that Access renames the current copy, then
compacts it into a file with the old name, and finally deletes the renamed
original. I can''t think of what a work-around might be for this problem.

你*可能*，这是严格的思考，能够捕获

这样的事件或导致这样的事件被写入事件日志，

你可以编写一个Windows服务来清理整个

对这次活动的回应很抱歉。当然，对于这么小的问题，这是相当多的工作，甚至可能都不起作用！


爱德华

You *might*, and this is strictly thinking aloud, be able to capture
such an event or cause such an event to be written to the Event Log,
and you could write a Windows Service that would clean up the whole
sorry mess in response to the event. Of course, this is quite a lot of
work for such a bitty problem, and it might not even work at all!

Edward

这篇关于紧凑的有趣问题。有什么想法消除？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！