记录访问应用程序 [英] documenting access apps
问题描述
我对ms访问开发有点熟悉，我被要求
端口并记录一个ms访问应用程序。我希望移植（97到XP）相当简单。
。然而记录它是另一回事。你如何
人们记录你的访问应用程序？
只需创建一个ERD并在vba代码中有注释？列出所有表格和
它的目的是什么？
我有什么方法/最佳实践/示例我可以看看吗？
谢谢提前
- jelmer
Access有一个内置的文档（工具 - 分析 - 文档管理器）那将是
打印有关db中对象的大量信息。访问
关系窗口也可以打印，虽然有时它不打印很好......但是，有一些第三方实用程序在那里
应该做得更好。
RE：移植 - 确保在新的Access XP中设置对DAO的引用
项目。
-
Scott McDaniel
CS计算机软件
Visual Basic - 访问 - Sql Server - ASP
在键盘上粉碎前额继续......
" Jelmer" < JK ****** @ planet.nl>在消息中写道
news：c0 ********** @ reader10.wxs.nl ...
我对ms访问开发有点熟悉，我被要求端口和文档ms访问应用程序。我希望移植（97到XP）相当简单。然而记录它是另一回事。
你们如何记录你的访问应用程序？
只需创建一个ERD并在vba代码中有注释？列出所有表格
及其用途？
我有什么方法/最佳实践/例子我可以看看吗？
提前谢谢
- jelmer
我认为Documenter可能适合非常简单的小应用程序。一个
平均应用程序可能会产生几千页长的文档，我认为这个文件不太实用。
我也有兴趣知道是否有更好的第三方工具
那里
NB
Jelmer写道：
我对ms访问开发有点熟悉，我被要求
端口并记录ms访问应用程序。我希望移植（97到XP）相当简单。然而记录它是另一回事。您如何记录您的访问应用程序？
我觉得这是一个非常敏感的问题。有些人根本就没有。
其他人写的评论多于实际的代码行，但是从来没有解释过/或单个查询存在的问题。
说到我自己，我最初根本没有文件，依靠
我的准确记忆力。这很有效。对我而言。
我和其他人一起做的第一个项目，那个方法
失败最惨烈。
我发现访问并不真正允许集中式方法。它很容易创建另一个查询，或者一个''临时''报告，看看
是否有效。如果您需要一个可靠的系统文档，您还需要
a项目经理（可能是您但需要相当多的纪律）
这是全部关于开发期间。当你需要在事后解开
完整的申请时，你必须通过
功能挖掘你的方式。通常我会尝试绘制表单层次结构（如果有的话）以获得
一些接口;我仔细研究了
表格/关系布局（不，我做布局，研究设计）。
对于后者，我发明了一些工具产生一个完整的
表/字段列表。我当然建议您查看我的网站上的工具部分，我的网站上的NavQueries，以及FindCode和
FindName有时会为我节省生命。
只需创建一个ERD并在vba代码中有注释？列出所有表格和
它的目的是什么？
我能看到的方法/最佳实践/示例吗？
提前感谢
您需要提前指定的内容并不容易。内置Documenter的巨大问题
是它产生数据，而不是信息。
许多细节都无关紧要，只是让页面变得杂乱无章。我试过一次
省略所有不偏离标准的设置（最常见的，或者
我的偏好，等等），但我没有时间完成那么。
Jelmer？你是荷兰人吗？
-
Bas Cost Budde
http://www.heuveltop.org/BasCB
但该域名为nl
Hi,
I am mildly familiar with ms access developement and I have been asked to
port and document a ms access app. I expect the porting (97 to XP) to be
fairly straightforward. However documenting it is another matter. How do you
people document your access apps?
Just create an ERD and have comments in the vba code? List all the forms and
it''s purpose ?
Are there any methodologies / best practices / examples I can look at?
thanks in advance
-- jelmer
Access has a builtin documenter (Tools - Analyze - Documenter) that will
print a fair amount of information about the objects in the db. The Access
Relationship window can also be printed, although sometimes it doesn''t print
very well ... however, there are some third-party utilities out there that
supposedly do a better job.
RE: Porting - make sure to set your reference to DAO in the new Access XP
project.
--
Scott McDaniel
CS Computer Software
Visual Basic - Access - Sql Server - ASP
"Smash forehead on keyboard to continue ... "
"Jelmer" <jk******@planet.nl> wrote in message
news:c0**********@reader10.wxs.nl...Hi,
I am mildly familiar with ms access developement and I have been asked to
port and document a ms access app. I expect the porting (97 to XP) to be
fairly straightforward. However documenting it is another matter. How do you people document your access apps?
Just create an ERD and have comments in the vba code? List all the forms and it''s purpose ?
Are there any methodologies / best practices / examples I can look at?
thanks in advance
-- jelmer
I think the Documenter may be good for very simple and small apps. An
average app may generate a few thousand page long document which, in
my opinion, is not very practical to go through.
I''m also interested to know if there is any better 3rd-party tool out
there
NB
Jelmer wrote:
Hi,
I am mildly familiar with ms access developement and I have been asked to
port and document a ms access app. I expect the porting (97 to XP) to be
fairly straightforward. However documenting it is another matter. How do you
people document your access apps?
I feel that is an *extremely* sensitive issue. Some people simply don''t.
Others write more comments than actual code lines, but never explain the
SQL for, or the existence of, a single query.
Speaking for myself, I initially did no documentation at all, relying on
my accurate adn strong memory. And that works. For me.
The very first project I did together with someone else, that approach
failed most miserably.
I find Access doesn''t really allow for a centralized approach. It is far
too easy to create just another query, or a ''temporary'' report to see if
something works. If you need a solid system documentation, you also need
a project manager (that can be you but that takes quite a lot of discipline)
This is all about during-development. When you need to unravel a
complete application afterwards, you must of course dig your way through
functionality. Usually I try to draw the form hierarchy, if any, to get
some hold of the interface; and I carefully study the
tables/relationships layout (no, I do the layout, and study the design).
For the latter, I''ve invented some tools that produce a complete
table/field list. I certainly suggest you look into the Tools section on
my site, NavQueries will be something for you but also FindCode and
FindName have been life savers for me sometimes.
Just create an ERD and have comments in the vba code? List all the forms and
it''s purpose ?
Are there any methodologies / best practices / examples I can look at?
thanks in advance
What you need is not easy to specify in advance. The enormous problem
with the built-in Documenter is that it produces data, not information.
Many details are irrelevant and just clutter the pages. I tried once to
omit all settings that do not deviate from a standard (most frequent, or
my preference, whatever) but I didn''t have time to finish that then.
Jelmer? You Dutch?
--
Bas Cost Budde
http://www.heuveltop.org/BasCB
but the domain is nl
这篇关于记录访问应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
