帮助腐败的表 [英] Help with corrupt table

问题描述

刚刚遇到我的第一个后端Access97数据库实例而不是
压缩。我收到MSACCESS.EXE已生成错误..

紧凑的消息。


我已经把它缩小到最大的表，其中包含了600k的记录。

我''我试过复制数据库并试图压缩它 - 不能工作。

我已经尝试过修复然后压缩也没有用。我曾试图创建一个新的数据库并导入表格，但是在导入损坏的表格的过程中，它的价格大约为5美元/ 8美元。我也不能出口

。我可以，一直查看桌面内容到

看起来的最后一条记录。


我正在考虑复制和粘贴大块文件一段时间进入表定义

的副本，但我不确定我是否可以保留现有的初级

密钥自动编号字段，除非我错过了一种方法这样做。是彼得吗？

米勒时间？


谢谢


Dan

Hi, just ran into my first instance of a backend Access97 database not
compacting. I''m getting the "MSACCESS.EXE has generated errors.." message on
compact.

I''ve narrowed it down to the largest table which cotains 600k of records.
I''ve tried copying the database and trying to compact that -doesn''t work.
I''ve tried Repair and then compact which also doesn''t work. I''ve tried to
create a new database and import the tables but it flakes out at about
5/8ths of the way through the import of the corrupt table. I can''t export
the table either. I can though, view the table contents all the way down to
the last record it seems.

I''m contemplating copying and pasting big chunks at a time into a copy of
the table definition, but am not sure if I can keep the exisiting primary
key autonumber field, unless I''m missing a way of doing this. Is it Peter
Miller time?

Thanks

Dan

推荐答案

Dan，


2004年1月14日星期三22:00 ：13-0000，Dan <无**** @ nospam.com>写道：

comp.databases.ms-access：

Dan,

On Wed, 14 Jan 2004 22:00:13 -0000, "Dan" <no****@nospam.com> wrote in
comp.databases.ms-access:

我正在考虑一次将大块复制并粘贴到
表定义，但我不确定我是否可以保留现有的主键自动编号字段，除非我错过了这样做的方法。是彼得吗？米勒时间？

I''m contemplating copying and pasting big chunks at a time into a copy of
the table definition, but am not sure if I can keep the exisiting primary
key autonumber field, unless I''m missing a way of doing this. Is it Peter
Miller time?

嗯，是的，不是。 ''是''在某种意义上说，好吧，我在这里，但是''不''

，因为这不是一个严重的问题，需要任何

专业技能。


继续并复制表格结构。一个附加查询然后

比复制和

粘贴更有意义带来''大块'，但是如果你*希望复制/粘贴，首先更改表

空表的结构，以便将pk自动编号字段设置为

a简单的长整数字段。复制并粘贴到您心中的内容，

但是您可能会发现一条或多条记录包含备忘录或字段

值已损坏且无法复制。复制所有记录，但是这些记录，复制所有字段，但有问题的

。正如我上面所说，追加查询更快速地执行此操作并且平稳地执行
，更重要的是，不需要修改pk字段

从autonumber到long int。 br />

无论如何，如果您确实采取了复制和粘贴路线，请记住将数据返回到表格结构的副本* * b $ b。在你打电话退出之前，有一个autonumber pk字段定义




Peter Miller

__________________________________________________ __________

PK解决方案 - Microsoft Access / Jet / SQL数据恢复

免费报价，保证最低价格和最佳结果
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051

Well, yes and no. ''Yes'' in the sense that, well, here I am, but ''No''
in the sense that this is not a serious issue requiring any
specialized skills.

Go ahead and duplicate the table structure. An append query then
makes more sense for bringing over ''big chunks'' than copying and
pasting, but if you *do* wish to copy/paste, first change the table
structure of the empty table so that the pk autonumber field is set to
a simple long integer field. Copy and paste to your hearts content,
but you''ll probably find one or more records with memo or ole field
values that are corrupt and will not copy. Copy all records but
these, and for these records, copy all fields but the problematic
ones. As I said above, append queries do this more quickly and
smoothly, and more to the point, do not require modifying the pk field
from autonumber to long int.

In any event, if you do take the copy and paste route, remember to
port the data back to a copy of the table structure that *does* have
an autonumber pk field definition before you call it quits.

Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051

Peter Miller < pm ***** @ pksolutions.com>

"Peter Miller" <pm*****@pksolutions.com>

Dan，

2004年1月14日星期三22:00:13 -0000，Dan <无**** @ nospam.com>写在
comp.databases.ms-access：

Dan,

On Wed, 14 Jan 2004 22:00:13 -0000, "Dan" <no****@nospam.com> wrote in
comp.databases.ms-access:

我正在考虑一次将大块复制并粘贴到表定义的副本中，但我不确定我是否可以保留现有的主要自动编号字段，除非我错过了这样做的方法。是彼得吗？米勒时间？

I''m contemplating copying and pasting big chunks at a time into a copy of
the table definition, but am not sure if I can keep the exisiting primary
key autonumber field, unless I''m missing a way of doing this. Is it Peter
Miller time?

嗯，是的，不是。 ''是''在某种意义上说，我是，但是''不''
，因为这不是一个需要任何专业技能的严重问题。

继续并复制表结构。添加查询然后
比复制和粘贴更有意义地带来''大块'，但如果你*希望复制/粘贴，首先更改表结构
结构空表的权限，以便将pk自动编号字段设置为一个简单的长整数字段。复制并粘贴到您的内容，
但您可能会找到一个或多个记录，其中包含备忘录或ole字段值已损坏且无法复制的值。复制所有记录，但这些记录，复制所有字段，但有问题的字段。正如我上面所说，追加查询更快速地执行此操作，并且更加顺利，不需要将pk字段从autonumber修改为long int。

任何事件，如果您确实采取了复制和粘贴路线，请记住将数据移回到表格结构的副本，*表格结构*具有自动编号pk字段定义，然后再调用它。

Peter Miller

Well, yes and no. ''Yes'' in the sense that, well, here I am, but ''No''
in the sense that this is not a serious issue requiring any
specialized skills.

Go ahead and duplicate the table structure. An append query then
makes more sense for bringing over ''big chunks'' than copying and
pasting, but if you *do* wish to copy/paste, first change the table
structure of the empty table so that the pk autonumber field is set to
a simple long integer field. Copy and paste to your hearts content,
but you''ll probably find one or more records with memo or ole field
values that are corrupt and will not copy. Copy all records but
these, and for these records, copy all fields but the problematic
ones. As I said above, append queries do this more quickly and
smoothly, and more to the point, do not require modifying the pk field
from autonumber to long int.

In any event, if you do take the copy and paste route, remember to
port the data back to a copy of the table structure that *does* have
an autonumber pk field definition before you call it quits.

Peter Miller

感谢您抽出宝贵时间回复Peter。


是的，我'首先按照你的建议尝试追加查询。


我有点担心为什么现在发生这种情况。我们从来没有能够在过去的7年中压缩数据库。我们已经拥有它。我通常每个月/两个月做一次
紧凑一次，从来没有遇到过问题。在我的脑海里

如果无法紧凑的应急方法不起作用，那就非常严重了。

（导入新数据库等）！我也想知道是否要反编译但是

看不到重点，因为这只是一个只有少数几个表的后端，没有反编译的
代码。


最后，如果我对此进行排序，你究竟如何经常检查这种类型的

腐败，或者你应该只发现它们当你

紧凑？如果是这种情况，我可能不得不考虑每日紧凑！


感谢您的帮助，


Dan

Thanks for taking the time to respond Peter.

Yes, I''ll try an append query first as you suggest.

I''m a bit concerned as to why it''s happened now. I''ve never been able to not
compact the database in the past 7 years we''ve had it. I normally do
compacts once every month/two months and never had a problem. In my mind
it''s quite serious if the unable-to-compact contingency methods don''t work
(import into new database etc)! I''m also wondering whether to decompile but
can''t see the point as this is a backend with only a handful of tables, no
code to decompile.

Lastly, if I do sort this out, how on earth do you check for this type of
corruption routinely, or are you supposed to discover them only when you
compact? I might have to think about daily compacting if that''s the case!

Thanks for your help,

Dan

2004年1月15日星期四00:09:12 -0000，Dan <无**** @ nospam.com>写道：

comp.databases.ms-access：

On Thu, 15 Jan 2004 00:09:12 -0000, "Dan" <no****@nospam.com> wrote in
comp.databases.ms-access:

感谢您抽出宝贵时间回复Peter。


欢迎您。

是的，我会按照您的建议先尝试追加查询。


好​​。

我有点担心为什么现在发生了。在过去的7年里，我从来没有能够压缩数据库。我通常每月/两个月做一次压缩，从来没有遇到过问题。


我认为每周一次，每两个月一次是一个好的时间表。我自己会每周推荐一次
，但只要它定期完成，

就没什么大不了的。当然，我在这里谈论生产。

在我看来，如果无法紧凑的应急方法不能正常工作，那就非常严重了。 >（导入新数据库等）！


好​​吧，他们不会。压缩程序失败的原因是系统表（严重）或数据表中的错误数据（不是严重的b $ b）有损坏
。后者就是你所经历的，并且整个表格（进口，出口，转换，压缩，

等）都会做同样的事情。原因 - Jet无法读取

损坏的字段值，因此无法完成操作。

我也想知道是否反编译但是
可以'看到这一点，因为这只是一个只有少数几个表的后端，没有反编译的代码。


在这种情况下没有意义。

最后，如果我对此进行排序，你究竟如何检查这种类型的

嗯，让我们保持透视。尝试读取

中的所有内容，该文件将告诉您文件中的所有内容是否都可以读取。

压缩这样做（和其他事情）。将所有内容导入e

新文件也可以。我没有看到任何理由为什么需要夜间压缩

。如果一个记录在周中获得了一个损坏的字段值，它的

为真，你可能直到本周结束才知道它，但即使你在周中发现了
，它不会阻止它发生。


基本上，你想尽你所能确保你的网络稳定，你的应用程序设计得很好。即便如此，在Jet中也不能防止腐败，但可以将其最小化。如果您发现最近发现的腐败现象，请修复它并继续前进。如果

腐败的发生频率高于你所熟悉的，并且

你已经尽了一切努力来提高稳定性，那么它的时间就是

考虑使用真正的客户端/服务器rdbms，如sql server，oracle，

postgresql，db2等。

感谢您的帮助，

Thanks for taking the time to respond Peter.
You''re welcome.
Yes, I''ll try an append query first as you suggest.
Good.
I''m a bit concerned as to why it''s happened now. I''ve never been able to not
compact the database in the past 7 years we''ve had it. I normally do
compacts once every month/two months and never had a problem.
I think once a week to once every two months is an ok schedule. I''d
recommend once a week myself, but as long as its done periodically,
its no big deal. Of course, I''m talking about production here.
In my mind
it''s quite serious if the unable-to-compact contingency methods don''t work
(import into new database etc)!
Well, they won''t. The reason the compact fails is that there is
damage to system tables (serious) or bad data in a data table (not
serious). The latter is what you experienced, and doing anything with
the table as a whole (importing, exporting, converting, compacting,
etc) will all fail for the very same reason - Jet can not read the
corrupted field value so it can not complete the action.
I''m also wondering whether to decompile but
can''t see the point as this is a backend with only a handful of tables, no
code to decompile.
There is no point in such a case.
Lastly, if I do sort this out, how on earth do you check for this type of
corruption routinely, or are you supposed to discover them only when you
compact? I might have to think about daily compacting if that''s the case!
Well, let''s keep perspective here. Attempting to read everything in
the file will tell you whether everything in the file can be read.
Compacting does this (and other things). Importing everything to e
new file does this too. I don''t see any reason why nightly compacts
are needed. If a record gains a corrupt field value mid week, its
true you may not know it until the end of the week, but even if you
found out mid-week, it does not prevent it from occurring.

Basically, you want to do what you can to ensure your network is
stable and your app well designed. Even so, corruption can not be
prevented in Jet, but it can be minimized. If you find corruption
like that you discovered recently, fix it and move forward. If the
corruption occurs more frequently than you are comfortable with, and
you have done everything you can to improve stability, then its time
to consider using a true client/server rdbms like sql server, oracle,
postgresql, db2, etc.
Thanks for your help,

非常欢迎您。


Peter Miller

__________________________________________________ __________

PK解决方案 - Microsoft Access / Jet / SQL的数据恢复

免费报价，保证最低价格和最佳结果
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051

You''re more than welcome.

Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051

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