DB自毁! < GRRRR> [英] DB Self-destructed! <GRRRR>

查看:51
本文介绍了DB自毁! < GRRRR>的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

(见前面的帖子记录太大)


今天早上我刚刚清除了所有早期的表格,保留了原始标签

分隔表格和表格,然后返回并完成了一个全新的数据库分割

并接受所有默认值。事情分裂了,字段改为日期/时间

&适当的备忘录,字段大小修剪到合理的数字,并保存

工作。重建数据输入/编辑表格并确保它指向新创建的表格的
。关闭MSAccess并返回并且

一切正常!然后我编辑了几个记录并且保存了b $ b ...再次它完美地工作了。没有''记录太大',没有错误的

全部。然后我点击Create New Record按钮,用Ctrl-C从

复制另一个文档中的一些文本,并将其粘贴到

记录之一的Memo字段中。 ..POOF,整个数据库现在由一个空记录组成(

AutoNumber拒绝创建记录号,并且不接受任何

数据任何领域)。除3之外的所有表格都已消失。关闭了

MSAccess并重新进入,剩下的3张桌子现在已经用了

表格。


这只是一个没有宏的简单数据库,没有代码,只有几个表格和

一个表格。


在系统周围搜索表格之后&安培;表格,我结束了

重新拆分(再次)原始制表符分隔表,再次接受所有

默认值并让系统创建新表。创建新表

后,在设计模式下进入新表以编辑字段

属性。编辑了前几个字段然后(惊喜)得到了记录

太大。 (!!!)


任何人都可以告诉我这里有什么< expletive deletedis

?我真的不想再花一整天来重复这个

练习,如果我错过了一些愚蠢的东西,可能会最终得到它

再次自毁。

杰克

解决方案

我通常推荐DIY,因为大多数人都可以用一点点建立一个数据库应用程序。 b $ b(或很多)这些团体的帮助或参加一些课程。可能

有助于保持理智,考虑需要有经验的Access

开发人员大约30到45分钟才能将电子表格规范化为db应用程序

有三个表(即两个父表和一个子表),导入

数据,并构建三个简单的数据输入/编辑表单,没有代码或宏。

清理6 MB的数据,然后进口可能需要15分钟 - 或几小时

和小时,具体取决于您的数据有多脏。


如果你有一个顾问面试你一个小时,找出你的需求

是什么,并检查你的系统,找出导致POOF!的原因。插曲,

花费另一个小时来构建数据库设计和导入例程,每小时花一半时间来解释他正在做什么和为什么(所以你学习这些有价值的

自己的技能)以及如何清理数据,并让你自己清理数据

,你可能会觉得它值得花费大约2

顾问时间半小时。


顾问还会建议其他改进来自动化您的数据库应用程序

除了他构建的那些简单对象之外,因为Access比没有代码或查询的简单数据库应用程序能够多得多。


Chris

Microsoft MVP

tekctrl写道:


>(参见前面的帖子Record is To Large) />
今天早上我刚刚删除了所有早期的表格,保留了原始选项卡
分隔表格和表格,然后重新进入并完成了一个全新的数据库拆分
并接受所有默认值。事情分裂,字段改为日期/时间
&备忘录酌情,字段大小修剪到合理的数字,并保存工作。重建数据输入/编辑表格并确保它指向新创建的表格。关闭MSAccess并重新进入并确保一切正常!然后我编辑了几条记录并保存了......再次完美地运行了。没有记录太大,没有错误的全部。然后我点击了Create New Record按钮,用Ctrl-C复制了另一个文档中的一些文本并将其粘贴到其中一个
记录中的Memo字段... POOF,整个DB现在由一个空记录组成(
AutoNumber拒绝为任何字段中的任何字段创建记录号并且不接受任何
数据)。除3之外的所有表格都已消失。关闭了
MSAccess并重新进入,剩下的3个表格现在已经和表格一起消失了。

这只是一个没有宏的简单数据库,没有代码,只需几张桌子和一张表格。

在系统周围搜寻桌子和桌子之后。表单,我最终重新拆分(再次)原始制表符分隔表,再次接受所有
默认值并让系统创建新表。创建新表后,在设计模式下进入新表以编辑字段
属性。编辑了前几个字段,然后(惊喜)得到记录
太大。 (!!!)

任何人都可以告诉我这里的< expletive deletedis
是什么?!?我真的不想再花一整天重复这个练习,如果我错过了一些愚蠢的东西,可能最终会再次自我毁灭。

Jack



-

通过AccessMonster.com发布消息
http://www.accessmonster.com/Uwe/For...ccess/200806/1


也许,你感到很沮丧,因为你认为Access应该以

a的方式行事,而不是。


我认为你从行/文件的文本文件开始,字段

用某些东西分隔?并且您要将此数据导入到

JET表中并在表单中进行编辑。


我建议您从此处发布一行或两行文本文件,如果有

a文本文件,并指出你想要对数据做什么一般

不是数据库条款。有人可能会提出建议,建议

可能会有效。

6月16日,7:36 * pm,tekctrl < tekc ... @ earthlink.netwrote:


今天早上我刚刚删除了所有早期的表格,保留了原始标签

分隔表格和表格,然后返回并完成了一个全新的数据库分割

并接受所有默认值。


无论是什么原因,我都不想做任何远程调试,它是一个

对象课程需要定期备份,特别是在制作

drastic之前像你一样修改。如果您属于备份是为了/ b $ b $ s sissies在此之前,我怀疑你现在正在考虑此事。

额外考虑。并且,如果你不得不像你说的那样,在表单和文件的周围寻找

系统,这是一个非常好的迹象,你没有立即执行

备份在激烈的mod之前。


当我在开发中时,我会在每个主要的b
之前制作一份备份副本 - 我愿意承担风险一个半小时到一个小时的工作赶上,但不再是
。当然,这并不意味着我必须每半小时支持一次b $ b(但我有时会这样做)。每个项目的开发文件夹都包含一个名为Backups的

文件夹,其中填充了按日期和时间标识的文件。


太,我给你的印象是链接到分隔文件和

实际上使用它作为表而不导入Access表...

会让你稍微暴露因为Jet和ACCDB数据库引擎

有内置的保护措施,文本文件是不可能的。这是一种方法

你可能想要重新考虑这是你正在做什么,或至少

讨论它,以及你在这里使用它的原因。


祝你康复工作好运。


Larry Linson

Microsoft Office Access MVP

(See earlier post "Record Is Too Large")

This morning I just wiped out all earlier tables, kept the original tab
delimited table and Form, then went back in and did a complete new DB split
and accepted all defaults. Got the thing split, fields changed to date/time
& memo as appropriate, field sizes trimmed to reasonable numbers, and saved
the work. Rebuilt the data entry/edit Form and insured that it was pointing
to the newly created tables. Closed MSAccess and went back in and
everything worked perfectly! I then edited several records and
saved...again it worked perfectly. No ''record is too large'', no err''s at
all. Then I clicked on the Create New Record button, copied some text from
another document with a Ctrl-C and pasted it into a Memo field in one of the
records...POOF, the entire DB now consists of a single empty record (which
AutoNumber refuses to create a record number for and which won''t accept any
data in any fields). All tables except for 3 were just gone. Closed
MSAccess and went back in, the remaining 3 tables were now gone along with
the Form.

This was just a simple DB with no macro''s, no code, just a few tables and
one Form.

After hunting all around the system for the tables & form, I ended up
re-splitting (again) the original tab delimited table, again accepting all
defaults and letting the system create the new tables. After the new tables
were created, went into the new tables in Design mode to edit the field
properties. Got the first few fields edited and then (surprise) got "Record
is too Large". (!!!)

Can anyone at all tell me just what the <expletive deletedis going on
here?!? I really don''t want to spend another Entire Day repeating this
exercise if I''m missing something stupid and might end up having it
self-destruct again.
Jack

解决方案

I normally recommend DIY because most people can build a db app with a little
(or a lot) of help from these groups or by taking some classes. It might
help preserve your sanity to consider it takes an experienced Access
developer about 30 to 45 minutes to normalize a spreadsheet into a db app
with three tables (that''s two parent tables and a child table), import the
data, and build three simple data entry/edit forms with no code or macros.
Cleaning up 6 MB of data before the imports could take 15 minutes -- or hours
and hours, depending on how dirty your data is.

If you had a consultant interview you for an hour to find out what your needs
are and to check your system to find out what caused that "POOF!" episode,
spend another hour building the db design and import routines, and spend half
an hour explaining what he''s doing and why (so you learn these valuable
skills yourself) and how to clean up the data, and let you clean up the data
for the imports yourself, you might find it well worth the cost for about 2
1/2 hours of a consultant''s time.

The consultant will also suggest other improvements to automate your db app
beyond those simple objects he builds because Access is capable of so much
more than a simple db app with no code or queries.

Chris
Microsoft MVP
tekctrl wrote:

>(See earlier post "Record Is Too Large")

This morning I just wiped out all earlier tables, kept the original tab
delimited table and Form, then went back in and did a complete new DB split
and accepted all defaults. Got the thing split, fields changed to date/time
& memo as appropriate, field sizes trimmed to reasonable numbers, and saved
the work. Rebuilt the data entry/edit Form and insured that it was pointing
to the newly created tables. Closed MSAccess and went back in and
everything worked perfectly! I then edited several records and
saved...again it worked perfectly. No ''record is too large'', no err''s at
all. Then I clicked on the Create New Record button, copied some text from
another document with a Ctrl-C and pasted it into a Memo field in one of the
records...POOF, the entire DB now consists of a single empty record (which
AutoNumber refuses to create a record number for and which won''t accept any
data in any fields). All tables except for 3 were just gone. Closed
MSAccess and went back in, the remaining 3 tables were now gone along with
the Form.

This was just a simple DB with no macro''s, no code, just a few tables and
one Form.

After hunting all around the system for the tables & form, I ended up
re-splitting (again) the original tab delimited table, again accepting all
defaults and letting the system create the new tables. After the new tables
were created, went into the new tables in Design mode to edit the field
properties. Got the first few fields edited and then (surprise) got "Record
is too Large". (!!!)

Can anyone at all tell me just what the <expletive deletedis going on
here?!? I really don''t want to spend another Entire Day repeating this
exercise if I''m missing something stupid and might end up having it
self-destruct again.

Jack

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200806/1


Perhaps, you are frustrated because you think Access should behave in
a way which it does not.

I think you start with a text-file of lines/records with fields
delimited with something? and that you want to import this data into a
JET table and edit it in a form.

I suggest that you post a line or two from this text file, if there is
a text file, and indicate what you want to do with the data in general
not "database" terms. Someone may make a suggestion and the suggestion
may work.
On Jun 16, 7:36*pm, "tekctrl" <tekc...@earthlink.netwrote:

This morning I just wiped out all earlier tables, kept the original tab
delimited table and Form, then went back in and did a complete new DB split
and accepted all defaults.


Whatever the cause, and I wouldn''t care to do any remote debugging, it is an
Object Lesson in the need for regular backups, ESPECIALLY before making
"drastic" modifications as you did. If you were among the "backups are for
sissies" contingent before, I suspect you are now giving the matter
additional consideration. And, if you had to, as you say, hunt around the
system for forms and files, that''s a pretty good indication you did not do a
backup immediately before the drastic mods.

When I am in development, I make a backup copy prior to every major
change -- I''m willing to risk a half-hour to an hour''s work catching up, but
no more. That, of course, doesn''t mean I have to back up every half-hour
(but I sometimes do so). Every project''s development folder contains a
folder named Backups, filled with files identified by date and time.

Too, I got the impression that you were linking to a delimited file and
actually using it as a table without importing into Access tables... that
will leave you "somewhat exposed" because the Jet and ACCDB database engines
have built-in safeguards that text files just can''t have. It is an approach
you might want to re-consider if that is what you are doing, or at least
discuss it, and your reasons for using it, here.

Best of luck with your recovery efforts.

Larry Linson
Microsoft Office Access MVP


这篇关于DB自毁! &LT; GRRRR&GT;的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆