Access 2003 - 如何最好地推动前端更新？ [英] Access 2003 - How best to push front end updates?

问题描述

作为一个警告，我是自学成才的，所以我养成了一种粗暴的习惯 - 强迫事情摆脱无知。我已经在网上搜索了一些并且没有找到解决方案，所以我认为如果有更好的选择，请问亲切的人不会有什么伤害。

问题

我有多个前端，几乎每天都会根据需求变化（或者我发现问题）进行更新。我需要一种简单的方法将前端的新本地副本推送到多台计算机。要求用户自己更换数据库是非常有问题的，因为生产车间的计算机专家很少。

我的想法

我我将创建一个PushTo访问数据库（2003），它将存储前端列表，以及存储程序的位置/目录列表。然后程序将循环通过用户选择的程序的位置，删除旧版本并从主文件夹复制较新版本。因此，每当我准备好新版本时，我都可以触发更新。


另一种想法是将代码放在前端，这将检查启动时是否是当前的或不。但是我不确定在程序处于活动状态时是否有办法触发自我删除/替换。

问题

有没有更简单的方法来做到这一点？我完全倒退了吗？


谢谢！

As a warning, I''m self-taught so I have a bad habit of brute-forcing things out of ignorance. I''ve done some searching online and haven''t found a solution, so I figured it couldn''t hurt to ask you kind folks if there was a better alternative.

PROBLEM
I have multiple front ends that are updated on an almost daily basis as needs change (or I find problems). I need an easy way to push out new local copies of the front ends to multiple computers. Asking the users to replace the database themselves is highly problematic as there are very few computer savvy people on the production floor.

MY IDEA
I was going to create a PushTo access database (2003) that would store a list of the front ends, and a list of the locations/directories where the programs are stored. The program would then cycle through the locations for the program selected by the user, deleting the old version and copying the newer one over from the master folder. Thus I could trigger an update whenever I had a new version ready to go.

The alternate thought was to put code inside the front ends that would check on startup to see if it was current or not. But I''m not sure if there is a way to trigger a self-delete/replacement while the program is active.

QUESTION
Is there any easier way to do this? Am I going about this completely backwards?

Thanks!

推荐答案

听起来你有几个好主意，但是让我问几件事。


1.所有的FE都是相同的吗？


2.所有用户都有访问您控制的网络位置？


我问的原因是这个...如果用户数量有限，他们应该能够共享一个前端。除此之外，通常更容易更改您控制的存储位置，而不是尝试访问用户的计算机。如果所有用户都挂钩到一个位置，您可以将前端存储在服务器上，并通过桌面上的快捷方式进行链接。然后你只需要更换服务器上的FE'，用户就会意识不到。


有几种方法可以做你想要的，但它会需要进一步了解才能找到最好的方法，所以请耐心等待。


希望这会有所帮助。


- Minion -

It sounds like you have a couple good ideas there, but let me ask a couple things.

1. Are all the FE''s identical?

2. Do all the users have access to a networked location that you control?

The reason I ask is this... If the number of users is limited they should be able to share a front end. Baring this it is generally easier to alter a stored location that you control than trying to access a user''s machine. If all the users were hooked to one location you could store the front ends on the server and they would link via shortcuts on their desktops. Then you would need only replace the FE''s on the server and the user would be blissfully unaware.

There are several ways to do what you are asking, but it''ll take some further understanding to find the best method so bear with me.

Hope this helps.

- Minion -

1.所有FE的相同吗？


2.所有用户都可以访问您控制的网络位置？

1. Are all the FE''s identical?

2. Do all the users have access to a networked location that you control?

这是一个有点复杂的地方，我希望我有一个白板可以涂鸦。 ^ _ ^ ;; *羞怯的样子*（咩！）


1.后端都存储在一个人人都可以访问的文件夹中。 （\\Fileserver \Databases）


2.前端（主副本）位于另一个文件夹中，每个人都可以访问，但对每个人都是只读的除了我。 （\\Fileserver \Databases \ Active副本的UI）这使得人们无法使用主副本，因为我需要或多或少地定期对它们进行处理。 *叹气*这也让他们更换本地副本如果它被破坏了（我还在教导主管怎么做。我真的需要在某些时候自动化它......）


3.有10个后端和22个前端，不包括尚未达到测试版的前端。这些前端中的每一个都具有独特的功能，从为各个部门和主管运行自定义报告，到在每个制造站记录不同的数据集。好好玩。但是，有几个这样的数据库可以在多台计算机上运行（例如Supervisor的生产数据库），那些是我需要强制更新的数据库。


3a 。有五十多个奇怪的用户，三十多个奇怪的电脑。计算机并不总是打开（叹气），因此我可能需要编写一些内容来记住它已更新的内容以及它没有的内容。 Hrmm .. *做笔记*


4.为什么本地副本而不是快捷方式？当多人使用相同的前端时，他们一直在腐败。此外，UI需要24/5运行（用于生产），但只需要在主动使用时链接到后端（5％的时间）。由于大部分用户从不同时处于活动状态，因此分解访问每个用户的后端更容易。因此，每个人都有一个本地副本，可以根据需要接收和删除后端连接。 （只有活动表被链接，静态表具有以编程方式同步的本地副本）


5.用户偷偷摸摸并继续将UI的副本移到我不喜欢的位置不知道。 （我经常在网络上运行搜索以尝试将其删除。）因此，我可能需要在UI本身中包含验证代码，以防止人们使用旧版本。

太多信息？还不够吗？

This is where it gets a little complicated, and the point where I wish I had a whiteboard to doodle on. ^_^;; *sheepish look* (baa!)

1. The back ends are all stored in one folder that is accessible to everyone. (\\Fileserver\Databases)

2. The front ends (master copies) are in another folder that is also accessible to everyone, but which is read-only to everyone but me. (\\Fileserver\Databases\Active Copies of UI) This stops folks from using the master copy, as I need to get in an work on them on a more or less regular basis. *sighs* This also lets them replace the local copy if it gets corrupted (something I''m still teaching the Supervisors how to do. I really need to automate it at some point...)

3. There are 10 back ends and 22 front ends, not counting the front ends that haven''t hit beta yet. Each of these front ends does something unique, from running custom reports for the various departments and supervisors, to recording a different data set at each manufacturing station. Such fun. However there are several of these databases that run on more than one computer (such as the Supervisor''s Production Database) and those are the ones I need to force updates on.

3a. There are fifty some-odd users, thirty some-odd computers. The computers are not always turned on (sigh) and thus I probably need to code in something that remembers what it has updated and what it hasn''t. Hrmm.. *makes notes*

4. Why local copies instead of shortcuts? They kept corrupting when multiple people used the same front end. Plus the UIs need to be running 24/5 (for production) but only need to link to the back ends when actively in use (5% of the time). Since the bulk of the users are never active at the same time, it''s easer to break down the back ends accessing to each user. Thus everyone has a local copy that can pick up and drop connections to the back ends as needed. (Only active tables are linked, static ones have local copies that are programmatically sync''d)

5. Users are sneaky and keep ferreting away copies of the UIs to locations I don''t know about. (I run a Search on the network every so often to try and kill them off.) So I probably need to include a validation code in the UIs themselves, just to keep folks from using the old versions.

Too much info? Not enough?

只是一个想法...


我有一个用户登录的应用程序。我在后端用户表上进行了查找，以查看用户所属的组。表单和菜单都由用户组驱动。一些形式和能力是在不同群体之间共享的，我称之为记者的群体。我只能查看和运行报告。


我的案例陈述可以为一个组打开一个只读表单，为另一个组打开一个完全访问权限。 case语句也可以启用/禁用函数。

Just a thought ...

I had a single application which users logged into. I did a lookup on the backend user table to see what group the user belonged to. The forms and menus were all driven by the user group. Some forms and capabilitlies were shared across groups and a group I called "reporters" were only able to view and run reports.

I had case statements which may open a form read-only for one group and full access for another. The case statements would enable/disable functions as well.

这篇关于Access 2003 - 如何最好地推动前端更新？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！