前端太多了？ [英] Too much in front end?

问题描述

最初作为一个简单的调度日志现在变成了一个完整的安全部门数据库...分类。

。我感谢很多人

，他们分享了他们的知识，帮助我完成了我所做的工作。


我们部门生成的所有内容，服务电话，

报告，财产库存等基于从调度数据库生成的数字

。正因为如此，我已经能够在不同的任务中完成不同的任务，所有这些都在相同的FE / BE设置中，但是FE已经变得越来越慢，我担心我会看到一个问题

数据被破坏或者真的是什么负面的。我的FE大约是4美元，并且每次登录时都会从服务器位置复制。这是为了在任何更改/更新后分发FE。


我的问题是这样，我会更好地为每个人提供多个FE >
单独的任务？ EG发送日志，财产日志，事故报告，

官员记录等？


再次感谢您过去和将来的帮助


Dave

What started out as a simple dispatching log has now turned into a
complete Security Department Databse...sorta. I thank many many people
who shared their knowledge to help me accomplish what I''ve done.

Everything that is generated in our department, service calls,
reports, property inventory, etc is based off of a number generated
from the dispatch database. Because of that, I have been able to
incorporate different tasks, all in the same FE/BE setup but the FE has
become increasingly slow and I am worried that I will see a problem
with data being corrupted or really anything negative. My FE is about
4mbs and is copied from the server location at each login. This is to
distribute the FE after any changes/updates.

My question is this, would I be better off having multiple FE for each
seperate task? EG Dispatch logs, property logs, incident reports,
officer records, etc.?

Thanks again for your past and future help

Dave

推荐答案

Per da ***** @ verizon.net ：

但是FE已经变得越来越慢，我担心我会看到一个问题
数据被破坏或实际上是负面的。我的FE大约是4mbs，并在每次登录时从服务器位置复制。这是为了在任何更改/更新后分发FE。

but the FE has
become increasingly slow and I am worried that I will see a problem
with data being corrupted or really anything negative. My FE is about
4mbs and is copied from the server location at each login. This is to
distribute the FE after any changes/updates.

我最大的前端是大约25兆，并且似乎没有任何表现

与那个尺寸相关的问题......那个或者用户只是麻木了

到那时......


如果在将其复制到用户的PC时等待是一个问题，您可以在前端的名称中添加一个

版本号并增强使用的批处理文件对于

副本，以便检查最新版本是否已经是

那里。


我的直觉是将应用程序分成多个前端将证明

对用户来说不方便/混乱，一旦它运行就没有加快速度。

-

PeteCresswell

My biggest front end was about 25 megs and there didn''t seem tb any performance
problems associated with that size.... either that or the users were just numb
by then....

If the wait while it''s copied down to the user''s PC is a problem, you can add a
version number to the front end''s name and enhance the batch file used for the
copy so that it checks to see if the latest-and-greatest version is already
there.

My intuition is that fragmenting the app into multiple front ends would prove
inconvenient/confusing for the users without speeding things up once it was
running.
--
PeteCresswell

我是Pete所说的第二个。我们的前端MDE大约是40 MB，我们运行它来自网络的
。没有特别的磨削性能问题。令我惊讶的是，虽然当我们从一台

本地硬盘驱动器运行应用程序时有明显的区别，但这并不像我预期的那么大，所以我们

离开网络上的实时应用程序并取消分发元素。


监控MDE的大小。它们可以像MDB一样膨胀。我有一个

方式将我的应用程序的模式从Live更改为开发等，然后

将所有表自动重新链接到正确的SQL Server实例。 />
每次我这样做，我的小40 MB MDE膨胀到大约250 MB。所以，我

压缩它，一切都很好。但随着用户进出，我可以看到它在网络上慢慢膨胀。这是一个缓慢膨胀，所以下一个

版本通常会出现并取代最后一个版本之前有一个问题，但在其他安排中，尺寸可能是问题。如果您的用户'

副本在本地计算机上停留的时间足够长，您可以看到那种问题。

I second what Pete says. Our front end MDE is about 40 MB, and we run it
FROM the network. No particular grinding performance problem. To my
surprise, although there is a clear difference when we run the app from a
local hard drive, it''s not as enormous a difference as I expected, so we
left the live app onthe network and eliminate the distribution element.

Monitor the size of the MDE. They can bloat the same as an MDB. I have a
way to change the mode of my app from Live to Development etc, and then
relink all the tables automatically to the correct instance of SQL Server.
Every time I do that my little 40 MB MDE bloats up to about 250 MB. So, I
compact it down and everything''s fine. But I can see it slowly bloating up
on the network as users get in and out. It''s a slow bloat, so the next
version usually comes out and replaces the last one before there''s a
problem, but in other arrangements size could be a problem. If your user''s
copy stays on the local machine long enough, you could see that sort of
problem.

尝试将所有内容导入到新的新数据库中。

这可能会有所帮助。


IMO 4 Mb对于前端来说并不是那么多或太多。

事实上，这根本不是很多......


几个问题：

有多少表格，查询''，我们在谈论报告吗？

多慢？越来越慢？还有一些用户也很慢？

什么版本的Access？


我猜这里还有其他问题。


Arno R


< da ***** @ verizon.net> schreef在bericht新闻：11 ********************** @ u72g2000cwu.googlegr oups.com ...

Try to import everything into a new, fresh database.
It might help.

IMO 4 Mb is not ''that much'' or ''too much'' for a Frontend.
In fact that''s not much at all ...

A few questions:
How many forms, query''s, reports are we talking about?
How slow is "increasingly slow"? Also slow with a few users?
What version of Access?

It''s my guess that there are other issues here.

Arno R

<da*****@verizon.net> schreef in bericht news:11**********************@u72g2000cwu.googlegr oups.com...

最开始的是什么一个简单的调度日志现在变成了一个完整的安全部门数据库... sorta。我感谢很多人，他们分享了他们的知识，帮助我完成了我所做的工作。

我们部门产生的一切，服务电话，报告，财产库存等基于从调度数据库生成的数字。正因为如此，我已经能够完成不同的任务，所有这些都在相同的FE / BE设置中，但FE已经变得越来越慢，我担心我会看到一个问题
数据被破坏或实际上是负面的。我的FE大约是4mbs，并在每次登录时从服务器位置复制。这是为了在任何更改/更新后分发FE。

我的问题是，我会更好地为每个单独的任务分配多个FE吗？ EG发送日志，财产日志，事故报告，官员记录等？

再次感谢您过去和将来的帮助

Dave

What started out as a simple dispatching log has now turned into a
complete Security Department Databse...sorta. I thank many many people
who shared their knowledge to help me accomplish what I''ve done.

Everything that is generated in our department, service calls,
reports, property inventory, etc is based off of a number generated
from the dispatch database. Because of that, I have been able to
incorporate different tasks, all in the same FE/BE setup but the FE has
become increasingly slow and I am worried that I will see a problem
with data being corrupted or really anything negative. My FE is about
4mbs and is copied from the server location at each login. This is to
distribute the FE after any changes/updates.

My question is this, would I be better off having multiple FE for each
seperate task? EG Dispatch logs, property logs, incident reports,
officer records, etc.?

Thanks again for your past and future help

Dave

这篇关于前端太多了？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！