在服务器上已打开数据库时复制数据库的FE [英] Copy FE of DB when it is already open on the server
问题描述
我刚刚更改了我的数据库，我正在从单片
数据库运行到分割FE / BE。前端位于客户端计算机上，并且BE位于网络驱动器上。
我正在试验由Tony Toews开发的实用工具
来处理软件的分发和随后的b $ b更新。我在实施的整体
升级过程中遇到了一些麻烦，我希望你们中的一个可能有一个想法怎么去？关于修复它。
只要用户按照
说明操作，该应用程序就可以正常运行。他们点击了一个快捷方式，这个快捷方式曾经导致旧的
单片数据库，但后来用一个简单的
形式切换出来，说明系统已升级。表单加载
事件转储到他们的桌面的快捷方式（由Tony的
实用程序创建的快捷方式）然后他们点击进入新拆分（和
从A97升级到A03）应用程序。
我遇到的第一个问题是我似乎无法获得升级db
在100％的时间内正确地将快捷方式转储到桌面。它是
工作9/10次，但似乎有些用户有一个不符合标准的桌面路径。如果它失败了，它会弹出一条消息与我联系，我手动发送它们
的快捷方式。我希望这可以100％的时间工作，但要做到这一点我需要某种通用路径，这将总是导致
当前用户''桌面而不是试图根据他们的
用户ID来推断它。
第二个问题要严重得多。一些用户有点技术精湛，并且决定我的快捷方式不够好
。他们在
网络上手动找到数据库的前端（Tony'的程序复制给每个用户的主副本）
并使用那个获取他们打开了主要副本
FE，没有其他人可以使用常规快捷方式打开
应用程序。这是因为你不能在文件打开时复制文件（至少你不能使用FileCopy）这一事实（我相信）。一个单独的人以错误的方式打开应用程序可以将
整个事情搞砸。
通过教育问题来纠正问题用户非常困难
，因为他们只有不到700个。他们收到了很多电子邮件和其他形式的更新，有些人最终得不到
备忘录，只需要一个人就可以了起来。什么让它变得更糟
就是这样一旦它被锁定，这就是打开它的唯一方法
（并且让他们完成他们的工作）是打开主FE文件数据库错误地打开它。他们发现很快就有了b / b
在各地拍摄电子邮件让人们进入'
秘密''。
为了纠正这个问题，我需要一些方法来确保它们绝对不能使用主要的FE数据库。但是，我不能让它自动关闭，因为它仍然需要复制到客户端机器上。如果我修改它以便它不会在网络上打开，那么它就不会在客户端机器上打开
。
我一直在考虑它，并提出了一些可能的b
解决方案，但我想知道你们中是否有人可能会有更好的想法或者/ br / >
评论。
创意1）为主FE文件创建一个新的网络文件夹，以便单独存在于
中（与放置相同）它与
后端在同一个文件夹中）。给公司里的每个人提供只读访问权限，并给自己的读/写访问权限。
缺点：需要长达2周的时间来完成所有的文件工作填写
和批准的更改（是的，我知道这是asinine。）此外，
我不确定它会起作用，因为人们仍然可以打开
它（虽然只是专门）甚至可以做一些表更新
（？），因为BE在一个文件夹中，他们有读/写访问权限。
想法2）编写一个在启动时运行的模块，以确定主FE文件夹中是否有一个ldb文件。如果有，试图删除
.ldb文件（如果最后一个用户
登录时它没有自动删除）然后关闭程序。这里的想法是，如果你正确登录
，你就不会在主FE文件夹中创建一个.ldb文件，但如果你登录不正确，那么
然后你将不可避免地在该目录中创建一个.ldb
文件，然后提示应用程序关闭。
Cons）我不是很擅长写作功能。我知道如何复制
文件以及如何删除一个，但不知道如何简单地检查是否存在。
也许我可以修补它并让它工作在一个回合的路上。
提前感谢您提供的任何建议。
首先，关于autoclose，您可以轻松地完成以下操作。当打开FE时，请使用currentproject.Path属性检查其路径。如果
所有用户都要将它安装在C盘上，那就做点什么
就好了，
如果剩下（ CurrentProject.Path，2）<" C："然后
msgbox"此应用程序必须安装在C盘上。申请
现在退出。，vbcritical
application.quit
结束如果
可能有比上述更优雅的解决方案。但这样可行。
另一种方法是将扩展名重命名为mydb.qde或类似的东西
。他们不知道那是什么。然后，当您将其复制到C
驱动器时，将其重命名为mydb.mdb。那也行。
Neil
< An *********** @ bcbsmn.comwrote in message
新闻：11 ********************** @ k35g2000prh.googlegr oups.com ...
>我刚刚将我的数据库从单片
DB更改为拆分FE / BE。前端位于客户端计算机上，并且BE位于网络驱动器上。
我正在试验由Tony Toews开发的实用工具
来处理软件的分发和随后的b $ b更新。我在实施的整体
升级过程中遇到了一些麻烦，我希望你们中的一个可能有一个想法怎么去？关于修复它。
只要用户按照
说明操作，该应用程序就可以正常运行。他们点击了一个快捷方式，这个快捷方式曾经导致旧的
单片数据库，但后来用一个简单的
形式切换出来，说明系统已升级。表单加载
事件转储到他们的桌面的快捷方式（由Tony的
实用程序创建的快捷方式）然后他们点击进入新拆分（和
从A97升级到A03）应用程序。
我遇到的第一个问题是我似乎无法获得升级db
在100％的时间内正确地将快捷方式转储到桌面。它是
工作9/10次，但似乎有些用户有一个不符合标准的桌面路径。如果它失败了，它会弹出一条消息与我联系，我手动发送它们
的快捷方式。我希望这可以100％的时间工作，但要做到这一点我需要某种通用路径，这将总是导致
当前用户''桌面而不是试图根据他们的
用户ID来推断它。
第二个问题要严重得多。一些用户有点技术精湛，并且决定我的快捷方式不够好
。他们在
网络上手动找到数据库的前端（Tony'的程序复制给每个用户的主副本）
并使用那个获取他们打开了主要副本
FE，没有其他人可以使用常规快捷方式打开
应用程序。这是因为你不能在文件打开时复制文件（至少你不能使用FileCopy）这一事实（我相信）。一个单独的人以错误的方式打开应用程序可以将
整个事情搞砸。
通过教育问题来纠正问题用户非常困难
，因为他们只有不到700个。他们收到了很多电子邮件和其他形式的更新，有些人最终得不到
备忘录，只需要一个人就可以了起来。什么让它变得更糟
就是这样一旦它被锁定，这就是打开它的唯一方法
（并且让他们完成他们的工作）是打开主FE文件数据库错误地打开它。他们发现很快就有了b / b
在各地拍摄电子邮件让人们进入'
秘密''。
为了纠正这个问题，我需要一些方法来确保它们绝对不能使用主要的FE数据库。但是，我不能让它自动关闭，因为它仍然需要复制到客户端机器上。如果我修改它以便它不会在网络上打开，那么它就不会在客户端机器上打开
。
我一直在考虑它，并提出了一些可能的b
解决方案，但我想知道你们中是否有人可能会有更好的想法或者/ br / >
评论。
创意1）为主FE文件创建一个新的网络文件夹，以便单独存在于
中（与放置相同）它与
后端在同一个文件夹中）。给公司里的每个人提供只读访问权限，并给自己的读/写访问权限。
缺点：需要长达2周的时间来完成所有的文件工作填写
和批准的更改（是的，我知道这是asinine。）此外，
我不确定它会起作用，因为人们仍然可以打开
它（虽然只是专门）甚至可以做一些表更新
（？），因为BE在一个文件夹中，他们有读/写访问权限。
想法2）编写一个在启动时运行的模块，以确定主FE文件夹中是否有一个ldb文件。如果有，试图删除
.ldb文件（如果最后一个用户
登录时它没有自动删除）然后关闭程序。这里的想法是，如果你正确登录
，你就不会在主FE文件夹中创建一个.ldb文件，但如果你登录不正确，那么
然后你将不可避免地在该目录中创建一个.ldb
文件，然后提示应用程序关闭。
Cons）我不是很擅长写作功能。我知道如何复制
文件以及如何删除一个，但不知道如何简单地检查是否存在。
也许我可以修补它并让它工作在一个回合的路上。
提前感谢您提供的任何建议。
"尼尔" < no **** @ nospam.netwrote：
>可能有一个比上面更优雅的解决方案。但那会有用。
同意。那将是我的建议。虽然这不一定是在终端服务器环境中工作，但是FE保存在文件服务器上。但是
可能会有一个工作。
>另一种方法是将扩展名重命名为mydb.qde或者<像那样。他们不知道那是什么。然后，当您将其复制到C
驱动器时，将其重命名为mydb.mdb。那也行。
我不知道。他的用户是一些偷偷摸摸的SOB。
Tony
-
Tony Toews，Microsoft Access MVP
请仅在新闻组中回复，以便其他人可以阅读整个邮件主题。
Microsoft Access Links，Hints，Tips&会计系统
http://www.granite.ab.ca /accsmstr.htm
Tony的Microsoft Access博客 - http://msmvps.com/blogs/access/
一个*********** @ bcbsmn.com 写道：
>我遇到的第一个问题是我似乎无法让我的升级db
在100％的时间内正确地将快捷方式转储到桌面。它可以工作9/10次，但似乎有些用户有一条不符合标准的桌面路径。
您真的想使用API调用来获取此信息。这就是我使用的。$
Auto FE Updater。 http://vbnet.mvps.org/code/shell/desktoplink。 htm
Tony
-
Tony Toews，Microsoft Access MVP
请只在新闻组中回复，以便其他人可以阅读整个消息主题。
Microsoft Access Links，Hints，Tips&会计系统
http://www.granite.ab.ca /accsmstr.htm
Tony的Microsoft Access博客 - http://msmvps.com/blogs/access/
I just recently changed my database that I''m running from a monolithic
DB to a split FE/BE. The front end resides on the client machine and
the BE resides on a network drive. I''m experimenting with a utility
developed by Tony Toews to handle the distribution and subsequent
updates of the software. I''m having some trouble with the overall
upgrade process I''ve implemented, and I''m hoping one of you may have
an idea how to go about fixing it.
The application works great so long as the users follow the
instructions. They click a shortcut, which used to lead to the old
monolithic database, but has since been switched out with a simple
form that explains that the system has been upgraded. The form load
event dumps a shortcut to their desktop (a shortcut made by Tony''s
utility) that they then click to get into the newly split (and
upgraded from A97 to A03) application.
The first problem I''m having is that I can''t seem to get my upgrade db
to correctly dump the shortcut to the desktop 100% of the time. It
works 9/10 times, but it would appear that some users have a path to
their desktop which is non conforming to the standard. If it fails, it
pops them a message to contact me and I manually send them the
shortcut. I would like this to work 100% of the time, but to do that I
would need some sort of generic path that will always lead to the
current user''s desktop rather than trying to infer it based on their
user id.
The second problem is far more serious. Some of the users are a little
more technically savvy, and decide that my shortcut is not good enough
for them. They manually locate the front end of the database on the
network (the master copy that Tony''s program copies out to each user)
and use that one to get in. The instant they open that master copy of
the FE, nobody else can use the regular shortcut to open the
application. This is caused (I believe) by the fact that you cannot
copy a file while it is open (at least you can''t using FileCopy). One
single person opening the application the wrong way can bring the
whole thing down.
Correcting the problem by educating the users is extremely difficult
as there are just under 700 of them. They get so many e-mails and
other forms of updates that some people wouldn''t end up getting the
memo, and it only takes one person to foul it up. What''s made it worse
is that once it is locked up like this, the only way to open it at all
(and for them to get their work done) is to open it incorrectly by
opening up the master FE database. They found that out quick and have
been shooting e-mails all over the place letting people in on ''the
secret''.
To correct this issue, I need some way to insure that they absolutely
cannot use the master FE database. However, I can''t just make it auto
close, because it still needs to be copied to the client machine. If I
modify it so that it won''t open on the network, then it won''t open on
their client machine either.
I''ve been thinking on it, and have come up with a few possible
solutions, but I wonder if any of you might have some better ideas or
comments.
Idea 1) Create a new network folder for the master FE file to exist in
by itself (as apposed to putting it in the same folder with the
backend). Give everybody in the company read only access and give
myself read/write access.
Cons: Would take up to 2 weeks to get all the paper work filled out
and the changes approved (yes, I know that is asinine.) Furthermore,
I''m not sure that it would work as people would still be able to open
it (albeit, only exclusively) and maybe even make some table updates
(?) as the BE is in a folder they would have read/write access to.
Idea 2) write a module that runs on startup to determine if there is
an ldb file in the master FE folder. If there is, attempt to delete
the .ldb file(in case it didn''t auto remove itself when the last user
logged in) then close the program. The idea here is that if you log in
properly, you won''t create an .ldb file in the master FE folder, but
if you did log in improperly then you will inevitably create an .ldb
file in that directory which then prompts the application to close.
Cons) I''m not really good at writing functions. I know how to copy a
file and how to delete one, but not how to simply check if one exists.
Maybe I can tinker with it and get it to work in a round about way.
Thanks in advance for any advice any of you may provide.
First, regarding autoclose, you can easily accomplish that as follows. When
the FE is opened, check its path, using the currentproject.Path property. If
all users are to have it installed on the C drive, then just do something
like,
If Left(CurrentProject.Path,2)<"C:" then
msgbox "This application must be installed on the C drive. Application
will now quit.", vbcritical
application.quit
End If
There might be a more elegant solution than the above. But that would work.
Another approach would be to rename the extension to mydb.qde or something
like that. They wouldn''t know what it was. Then, when you copy it to the C
drive, rename it to mydb.mdb. That would also work.
Neil
<An***********@bcbsmn.comwrote in message
news:11**********************@k35g2000prh.googlegr oups.com...>I just recently changed my database that I''m running from a monolithic
DB to a split FE/BE. The front end resides on the client machine and
the BE resides on a network drive. I''m experimenting with a utility
developed by Tony Toews to handle the distribution and subsequent
updates of the software. I''m having some trouble with the overall
upgrade process I''ve implemented, and I''m hoping one of you may have
an idea how to go about fixing it.
The application works great so long as the users follow the
instructions. They click a shortcut, which used to lead to the old
monolithic database, but has since been switched out with a simple
form that explains that the system has been upgraded. The form load
event dumps a shortcut to their desktop (a shortcut made by Tony''s
utility) that they then click to get into the newly split (and
upgraded from A97 to A03) application.
The first problem I''m having is that I can''t seem to get my upgrade db
to correctly dump the shortcut to the desktop 100% of the time. It
works 9/10 times, but it would appear that some users have a path to
their desktop which is non conforming to the standard. If it fails, it
pops them a message to contact me and I manually send them the
shortcut. I would like this to work 100% of the time, but to do that I
would need some sort of generic path that will always lead to the
current user''s desktop rather than trying to infer it based on their
user id.
The second problem is far more serious. Some of the users are a little
more technically savvy, and decide that my shortcut is not good enough
for them. They manually locate the front end of the database on the
network (the master copy that Tony''s program copies out to each user)
and use that one to get in. The instant they open that master copy of
the FE, nobody else can use the regular shortcut to open the
application. This is caused (I believe) by the fact that you cannot
copy a file while it is open (at least you can''t using FileCopy). One
single person opening the application the wrong way can bring the
whole thing down.
Correcting the problem by educating the users is extremely difficult
as there are just under 700 of them. They get so many e-mails and
other forms of updates that some people wouldn''t end up getting the
memo, and it only takes one person to foul it up. What''s made it worse
is that once it is locked up like this, the only way to open it at all
(and for them to get their work done) is to open it incorrectly by
opening up the master FE database. They found that out quick and have
been shooting e-mails all over the place letting people in on ''the
secret''.
To correct this issue, I need some way to insure that they absolutely
cannot use the master FE database. However, I can''t just make it auto
close, because it still needs to be copied to the client machine. If I
modify it so that it won''t open on the network, then it won''t open on
their client machine either.
I''ve been thinking on it, and have come up with a few possible
solutions, but I wonder if any of you might have some better ideas or
comments.
Idea 1) Create a new network folder for the master FE file to exist in
by itself (as apposed to putting it in the same folder with the
backend). Give everybody in the company read only access and give
myself read/write access.
Cons: Would take up to 2 weeks to get all the paper work filled out
and the changes approved (yes, I know that is asinine.) Furthermore,
I''m not sure that it would work as people would still be able to open
it (albeit, only exclusively) and maybe even make some table updates
(?) as the BE is in a folder they would have read/write access to.
Idea 2) write a module that runs on startup to determine if there is
an ldb file in the master FE folder. If there is, attempt to delete
the .ldb file(in case it didn''t auto remove itself when the last user
logged in) then close the program. The idea here is that if you log in
properly, you won''t create an .ldb file in the master FE folder, but
if you did log in improperly then you will inevitably create an .ldb
file in that directory which then prompts the application to close.
Cons) I''m not really good at writing functions. I know how to copy a
file and how to delete one, but not how to simply check if one exists.
Maybe I can tinker with it and get it to work in a round about way.
Thanks in advance for any advice any of you may provide.
"Neil" <no****@nospam.netwrote:
>There might be a more elegant solution than the above. But that would work.Agreed. That was going to be my suggestions. Although that wouldn''t necessarily
work in a Terminal Server environment where the FE is kept on a file server. However
there could be a work around there.
>Another approach would be to rename the extension to mydb.qde or something
like that. They wouldn''t know what it was. Then, when you copy it to the C
drive, rename it to mydb.mdb. That would also work.I dunno. His users are some sneaky SOBs.
Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony''s Microsoft Access Blog - http://msmvps.com/blogs/access/
An***********@bcbsmn.com wrote:
>The first problem I''m having is that I can''t seem to get my upgrade db
to correctly dump the shortcut to the desktop 100% of the time. It
works 9/10 times, but it would appear that some users have a path to
their desktop which is non conforming to the standard.You really want to use the API call to get this information. Which is what I use.un
the Auto FE Updater. http://vbnet.mvps.org/code/shell/desktoplink.htm
Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony''s Microsoft Access Blog - http://msmvps.com/blogs/access/
这篇关于在服务器上已打开数据库时复制数据库的FE的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
