连续写入/读取MDB [英] Continuous writing/reading to MDB

问题描述

我有一个包含单个表的MDB。检重秤数据通过网络从专用工作站连续写入此MDB，并以每分钟约120条记录的速率进入服务器上的MDB
。这个

将来可能会增加到200左右。记录不大。


我们有其他工作站在终端服务器查询上运行会话
这个MDB，用于绘制图表上的最后几小时数据或运行其他报告的
，甚至只是查看原始数据。没有人会写给MDB

。


任何人都可以看到任何潜在的问题。


我我担心在写作过程中丢失的网络连接以及有损坏的MDB的
。速度问题是另一个问题。我们预计每天会有70-80,000

的记录，这意味着在一天结束时可能会出现大量的延迟。 MDB将每天存档，并且第二天
开始为空。


我没有看到任何锁定问题。


Jeff

I have an MDB that contains a single table. Checkweigher data is being
continuously written to this MDB from a dedicated workstation over a network
into the MDB on the server at the rate of about 120 records a minute. This
may increase in the future to about 200. The records are not large.

We have other workstations that run sessions on Terminal Server querying
this MDB, doing things like plotting the last hours data on a graph or
running other reports, or even just viewing raw data. No one else will be
writing to the MDB.

Can anyone see any potential problems.

I am concerned with the network connection being lost during the writing and
having a corrupted MDB. The issue of speed is another. We expect 70-80,000
records a day which means that there could be a substantial delay in
querying towards the end of the day. The MDB will be archived each day and
start empty the next day.

I don''t see any locking issues.

Jeff

推荐答案

当您使用文件服务器数据库时，这总是一个
$ b $考虑。你是否应该考虑替代方案将取决于

任务关键型这是 - 也就是说，当您进行压缩/维修时，您的公司需要花费多少？b $ b它将停止服务？如果你没有成功修复，并且不得不从备份中恢复，那么它会花多少钱？你怎么会追赶？从备份到当前的更新？


您可以告诉管理层，他们可能会认为它不是所有大笔交易

和使用文件服务器（Jet）数据库;或者您可能会听到管理层的呼吸急剧下降。具有完全零售的比较成本

SQL Server准备就绪，以便他们可以看到有多少点击支付包装费用。

我从一个性能/用户受众大小的角度研究了几个可以用文件服务器完成的数据库

，但是完成了客户端

服务器因为它们对操作的重要性以及服务器数据库的优越性和可恢复性。


Larry Linson

Microsoft Access MVP

" Jeff Pritchard" < JE ************ @ asken.com.au>在留言中写道

新闻：8H *************** @ news.optus.net.au ...

When you are working with a file-server database, this is always a
consideration. Whether you should consider alternatives would depend on how
"mission-critical" this is -- that is, what would it cost your company for
it to be out of service while you Compact/Repair? What would it cost if you
couldn''t successfully repair, and had to restore from a backup? How would
you "catch up" the updates from the backup to current?

You may tell management and they may decide it''s not "all that big a deal"
and to go with the file-server (Jet) database; or you may hear a sharp
intake of breath from management. Have the comparison costs of full retail
SQL Server ready so they can see how many "hits" it would take to pay pack.
I have worked on a few databases that could have been done with file server
from a performance/user audience size point of view, but were done client
server because of their importance to the operation and the superior
reliability and recoverability of the server DB.

Larry Linson
Microsoft Access MVP

"Jeff Pritchard" <je************@asken.com.au> wrote in message
news:8H***************@news.optus.net.au...

我有包含单个表的MDB。检重秤数据正在通过
网络从专用工作站连续写入MDB，进入服务器上的MDB，速率约为每分钟120条记录。这个
将来可能会增加到200左右。记录不是很大。

我们有其他工作站在终端服务器上运行会话查询这个MDB，做一些事情，比如绘图图表上的最后几小时数据或运行其他报告，甚至只是查看原始数据。没有人会写给MDB。

任何人都可以看到任何潜在的问题。

我担心写作过程中丢失的网络连接
并且MDB已损坏。速度问题是另一个问题。我们预计每天会有70-80,000条记录，这意味着在一天结束时查询可能会有很大的延迟。 MDB将每天存档，并在第二天开始清空。

我没有看到任何锁定问题。

Jeff

I have an MDB that contains a single table. Checkweigher data is being
continuously written to this MDB from a dedicated workstation over a network into the MDB on the server at the rate of about 120 records a minute. This
may increase in the future to about 200. The records are not large.

We have other workstations that run sessions on Terminal Server querying
this MDB, doing things like plotting the last hours data on a graph or
running other reports, or even just viewing raw data. No one else will be
writing to the MDB.

Can anyone see any potential problems.

I am concerned with the network connection being lost during the writing and having a corrupted MDB. The issue of speed is another. We expect 70-80,000
records a day which means that there could be a substantial delay in
querying towards the end of the day. The MDB will be archived each day and
start empty the next day.

I don''t see any locking issues.

Jeff

2003年11月15日星期六01:54:12 GMT，Jeff Pritchard

< je *** *********@asken.com.au>写道：


每秒3到5个记录（或更高？）的峰值附加率相当高或者高b $ b。我需要一个小时左右的时间来编写一个简单的概念验证

应用程序，以确保您的系统能够处理它。每隔200

毫秒勾选一个计时器并追加一行。然后在该表中添加100,000行并再次尝试
。


我不关心SELECT查询。索引的力量

应该确保你查询100行或者$ b $ 100,000 100,000几乎不重要。除了一些增加的网络流量。你甚至可以让b / b $ b $让那些家伙点击一个单独的数据库，你可以通过第一个数据库中的数据转储来填充每个

。


访问IMHO不是一个24/7数据库。我会倾向于SQL Server

数据库。


-Tom。

On Sat, 15 Nov 2003 01:54:12 GMT, "Jeff Pritchard"
<je************@asken.com.au> wrote:

A peak append rate of 3 - 5 records (or higher?) per second is rather
high. I would take an hour or so to write a simple proof-of-concept
app to make sure your system can handle that. Tick a timer every 200
msec and append a row. Then add 100,000 rows to that table and try
again.

I''m not that concerned about the SELECT queries. The power of indexing
should ensure it hardly matters whether you''re querying 100 rows or
100,000. Except for some increased network traffic. You could even
have those guys hitting a separate database, which you populate every
so often with a data dump from the first database.

Access IMHO is not a 24/7 database. I would lean towards a SQL Server
database for this.

-Tom.

我有一个包含单个表的MDB。检重秤数据通过网络连续写入MDB，从专用工作站通过网络连接到服务器上的MDB，速率约为每分钟120条记录。这个
将来可能会增加到200左右。记录不是很大。

我们有其他工作站在终端服务器上运行会话查询这个MDB，做一些事情，比如绘图图表上的最后几小时数据或运行其他报告，甚至只是查看原始数据。没有人会写给MDB。

任何人都可以看到任何潜在的问题。

我担心写作过程中丢失的网络连接
有一个损坏的MDB。速度问题是另一个问题。我们预计每天会有70-80,000条记录，这意味着在一天结束时查询可能会有很大的延迟。 MDB将每天存档并在第二天开始清空。

我没有看到任何锁定问题。

Jeff

I have an MDB that contains a single table. Checkweigher data is being
continuously written to this MDB from a dedicated workstation over a network
into the MDB on the server at the rate of about 120 records a minute. This
may increase in the future to about 200. The records are not large.

We have other workstations that run sessions on Terminal Server querying
this MDB, doing things like plotting the last hours data on a graph or
running other reports, or even just viewing raw data. No one else will be
writing to the MDB.

Can anyone see any potential problems.

I am concerned with the network connection being lost during the writing and
having a corrupted MDB. The issue of speed is another. We expect 70-80,000
records a day which means that there could be a substantial delay in
querying towards the end of the day. The MDB will be archived each day and
start empty the next day.

I don''t see any locking issues.

Jeff

嗨拉里


鉴于数据每天都存档，只有

输掉一天的数据。该数据仅用于监控权重。多年来他们已经运行了多年没有这个，他们的方法是它不是任务

关键。虽然不是理想的丢失天数据，但它不会停止生产。


我们只会在归档时进行压缩。即使那时可能没有必要

，因为我们只需用空副本替换MDB。


在工作站上设置MSDE的想法被提出但是我认为，
不能合法地从多个工作站访问这个。


你认为在数据<时，其他人查询时会出现问题吗？ br />
是不是一直写的？


杰夫

" Larry Linson" <博***** @ localhost.not>在消息中写道

新闻：hp ***************** @nwrddc02.gnilink.net ...

Hi Larry

Given that the data is archived each day, there is only the possibility of
losing a days data. The data is for monitoring weights only. They have run
for years without this and their approach is that it is not mission
critical. While not ideal to lose a days data, it is not going to stop
production.

We would only compact when it is archived. Even then probably not necessary
as we would simply replace the MDB with an empty copy.

The thought of setting up MSDE on the workstation was raised but then they
can''t legally access this from multiple workstations, I think.

Do you think there will be a problem with others querying while data is
being continually written?

Jeff
"Larry Linson" <bo*****@localhost.not> wrote in message
news:hp*****************@nwrddc02.gnilink.net...

当你正在使用文件服务器数据库，这始终是一个考虑因素。您是否应该考虑替代方案将取决于
任务关键如何这是 - 也就是说，当您进行压缩/维修时，您的公司会因为停止服务而花费多少？如果
你无法成功修复，并且必须从备份中恢复，会花多少钱？你怎么会赶上从备份到当前的更新？

您可能会告诉管理层，他们可能会认为它不是那么大的交易，而是与文件服务器一起使用（ Jet）数据库;或者你可能会听到管理层的呼吸声。完全零售的比较成本SQL Server准备就绪，这样他们就可以看到有多少点击它需要支付
包。我已经从性能/用户受众大小的角度研究了一些可以用文件
服务器完成的数据库，但是由于它们对操作和上级的重要性而完成了客户端服务器服务器数据库的可靠性和可恢复性。

Larry Linson
Microsoft Access MVP

Jeff Pritchard < JE ************ @ asken.com.au>在消息中写道
新闻：8H *************** @ news.optus.net.au ...

When you are working with a file-server database, this is always a
consideration. Whether you should consider alternatives would depend on how "mission-critical" this is -- that is, what would it cost your company for
it to be out of service while you Compact/Repair? What would it cost if you couldn''t successfully repair, and had to restore from a backup? How would
you "catch up" the updates from the backup to current?

You may tell management and they may decide it''s not "all that big a deal"
and to go with the file-server (Jet) database; or you may hear a sharp
intake of breath from management. Have the comparison costs of full retail
SQL Server ready so they can see how many "hits" it would take to pay pack. I have worked on a few databases that could have been done with file server from a performance/user audience size point of view, but were done client
server because of their importance to the operation and the superior
reliability and recoverability of the server DB.

Larry Linson
Microsoft Access MVP

"Jeff Pritchard" <je************@asken.com.au> wrote in message
news:8H***************@news.optus.net.au...

我有一个包含的MDB一张桌子。检重秤数据通过

I have an MDB that contains a single table. Checkweigher data is being
continuously written to this MDB from a dedicated workstation over a

网络

从专用工作站连续写入MDB，进入服务器上的MDB，速率约为120条记录a分钟。
这可能会在未来增加到200左右。记录不是很大。

我们有其他工作站在终端服务器上运行会话查询这个MDB，做一些事情，比如绘图图表上的最后几小时数据或运行其他报告，甚至只是查看原始数据。没有其他人愿意写信给MDB。

任何人都可以看到任何潜在的问题。

我担心写作过程中丢失的网络连接

into the MDB on the server at the rate of about 120 records a minute. This may increase in the future to about 200. The records are not large.

We have other workstations that run sessions on Terminal Server querying
this MDB, doing things like plotting the last hours data on a graph or
running other reports, or even just viewing raw data. No one else will be writing to the MDB.

Can anyone see any potential problems.

I am concerned with the network connection being lost during the writing

和

MDB已损坏。速度问题是另一个问题。我们预计每天会有
70-80,000条记录，这意味着在当天结束时可能会有很长时间的查询延迟。 MDB将每天存档
并在第二天开始清空。

我没有看到任何锁定问题。

Jeff

having a corrupted MDB. The issue of speed is another. We expect 70-80,000 records a day which means that there could be a substantial delay in
querying towards the end of the day. The MDB will be archived each day and start empty the next day.

I don''t see any locking issues.

Jeff

这篇关于连续写入/读取MDB的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！