Access作为前端的缺点 [英] Disadvantage of Access as front-end

查看:218
本文介绍了Access作为前端的缺点的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

您好,


我们正在检查当前的主要应用程序。我们必须做一些重大更改,并且在此过程中,正在质疑/验证使用MS Access作为前端的

。该应用程序相对较大:大约200

表,200个表单和子表单,150个查询和150个repports,5GB数据

(SQL Server 2000),40个用户。


我想知道使用Access作为前端的缺点是什么?其他

,浏览器无法访问它。是否涉及执行速度

问题?我们有没有现实的有关

开发速度的替代方案?其他人用来构建客户服务器数据库

这种规模的应用,不会出售给任何人,永久演变?


这几乎是哲学!欢迎提出所有反馈意见。


Yannick

解决方案

我是一个Access倡导者,并且我认为Access可以做你想要的,

但是有很多表格,查询等等,你可能会因为一个非常好的开发人员使用的小b
团队而感觉更好类似于Java,C#,Smalltalk,

Delphi,或其他类似的东西。


基本上,有很多对象,即使它需要更长的时间来设计你的原型对象,使用继承和自动生成更容易实现
生成以降低成本并提高一致性,推出

你想到的对象数量。


关于报告的说明。我有点偏颇,但我不知道是否有任何报告以及Access的报告。由于Access通过COM公开了一个对象模型,或许是b $ b,因此使用Access作为UI是有意义的,但是生成Access

前端数据库和所有使用的对象来自其他语言的自动化

,如C#,Python或Ruby。因此,您的来源虽然运行时产品是Access前端,但代码在Access中甚至不是
。在这种情况下,C#很不错,因为它使COM集成变得非常简单,但是Python和Ruby使得它更容易进行文本解析,模板等等。生成VBA鳕鱼

Access应用程序将在运行时使用。


代码生成方法的另一个好处是你可以修改

生成器代码稍后使用相同的模板生成Web界面

在ASP.NET,Struts或Zope中。


有一个看看代码生成在行动作者:Jack Herrington。


周五,2004年7月16日10:52:33 -0400,Yannick Turgeon < no **** @ nowhere.com>

写道:

你好,

我们正在进行中检查我们当前的主要应用。我们必须做一些重大更改,并在此过程中质疑/验证MS Access作为前端的使用。应用程序相对较大:大约200个表,200个表单和子表单,150个查询和150个重载,5GB数据(SQL Server 2000),40个用户。

>我想知道使用Access作为前端的缺点是什么?其他
用浏览器无法访问它。是否涉及执行速度问题?我们有没有现实的关于
发展速度的替代方案?其他人正在使用什么来构建客户服务器数据库
这种规模的应用,而不是出售给任何人,在永久演变中?

这几乎是哲学!欢迎所有反馈。

Yannick




好奇。您使用的是DAO / ODBC还是ADP?


使用Windows终端处理网络访问对我来说更容易 - 更快 -

服务。有40个用户,我建议,如果你使用DAO / ODBC,那么更多的是
(虽然很难相信你会用5GB的数据做到这一点)分享)。


" Yannick Turgeon" <无**** @ nowhere.com>在消息中写道

news:cX ********************* @ news20.bellglobal.com ...

您好,

我们正在检查我们当前的主要应用程序。我们有
进行一些重大更改,并且在此过程中,正在质疑/验证MS Access作为前端的使用。该应用程序相对较大:大约
200个表,200个表单和子表单,150个查询和150个repports,5GB数据
(SQL Server 2000),40个用户。
我想知道使用Access作为前端的缺点是什么?
另外,浏览器无法访问它。是否涉及执行速度问题?我们有没有现实的关于
发展速度的替代方案?其他人正在使用什么来构建客户服务器数据库
这种规模的应用,而不是出售给任何人,在永久演变中?

这几乎是哲学!欢迎提出所有反馈。

Yannick



对不起所有的拼写错误。

星期五,2004年7月16日15:32:34 GMT,Steve Jorgensen< no **** @ nospam.nospam>

写道:

我是一个Access倡导者,我认为Access可以做你想做的事情,
但是有了很多表格,查询等,你可能会用一个小的

....


Hello,

We are in the process of examining our current main application. We have to
do some major changes and, in the process, are questionning/validating the
use of MS Access as front-end. The application is relatively big: around 200
tables, 200 forms and sub-forms, 150 queries and 150 repports, 5GB of data
(SQL Server 2000), 40 users.

I''m wondering what are the disadvantages of using Access as front-end? Other
that it''s not accessible with a browser. Is there any execution speed
question involved? Do we have any "realistic" alternatives regarding
development speed? What others are using to build client-serveur database
application of that size, not sold to anybody, in permanent evolution?

It''s almost philosophy! All feedback are welcome.

Yannick

解决方案

I''m somthing of an Access advocate, and I think Access can do what you want,
but with that many forms, queries, etc., you might be better off with a small
team of really good developers using something like Java, C#, Smalltalk,
Delphi, or something along those linse.

Basically, with that many objects, even though it''ll take longer to design
your prototype objects, it''ll be easier to use inheritance and automatic cose
generation to reduce the cost and increase the consistency, putting out the
number of objects you have in mind.

A note on reports. I''m a bit biased, but I don''t know if anything does
reports as well as Access does. Since Access exposes an object model via COM,
perhaps, it would make sense to use Access as the UI, but generate the Access
front-end database and all objects using automation from some other language
such as C#, Python, or Ruby. Thus, your "source" code is not in Access even
though the run-time product is an Access front-end. C# is nice in this case,
because it makes COM integration pretty easy, but Python and Ruby make it
easier to do the text parsing, templates, etc., to generate the VBA cod the
Access app will use at run-time.

Another nice thing about the code generation approach is that you can modify
the generator code later to use the same templates to generate Web interfaces
in ASP.NET, Struts, or Zope.

Have a look at "Code Generation In Action" by Jack Herrington.

On Fri, 16 Jul 2004 10:52:33 -0400, "Yannick Turgeon" <no****@nowhere.com>
wrote:

Hello,

We are in the process of examining our current main application. We have to
do some major changes and, in the process, are questionning/validating the
use of MS Access as front-end. The application is relatively big: around 200
tables, 200 forms and sub-forms, 150 queries and 150 repports, 5GB of data
(SQL Server 2000), 40 users.

I''m wondering what are the disadvantages of using Access as front-end? Other
that it''s not accessible with a browser. Is there any execution speed
question involved? Do we have any "realistic" alternatives regarding
development speed? What others are using to build client-serveur database
application of that size, not sold to anybody, in permanent evolution?

It''s almost philosophy! All feedback are welcome.

Yannick




Just curious. Are you using DAO/ODBC or ADP?

Dealing with Access over network is much easier for me now - and faster -
with the use of Windows Terminal Services. With 40 users, I suggest it,
more of that if ever you are using DAO/ODBC (although it is hard to
believel you would do so with 5GB of data to share).


"Yannick Turgeon" <no****@nowhere.com> wrote in message
news:cX*********************@news20.bellglobal.com ...

Hello,

We are in the process of examining our current main application. We have to do some major changes and, in the process, are questionning/validating the
use of MS Access as front-end. The application is relatively big: around 200 tables, 200 forms and sub-forms, 150 queries and 150 repports, 5GB of data
(SQL Server 2000), 40 users.

I''m wondering what are the disadvantages of using Access as front-end? Other that it''s not accessible with a browser. Is there any execution speed
question involved? Do we have any "realistic" alternatives regarding
development speed? What others are using to build client-serveur database
application of that size, not sold to anybody, in permanent evolution?

It''s almost philosophy! All feedback are welcome.

Yannick



Sorry for all the typos.

On Fri, 16 Jul 2004 15:32:34 GMT, Steve Jorgensen <no****@nospam.nospam>
wrote:

I''m somthing of an Access advocate, and I think Access can do what you want,
but with that many forms, queries, etc., you might be better off with a small


....


这篇关于Access作为前端的缺点的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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