可分发的商业应用访问与德尔福 [英] Distributable Commercial Apps Access Vs Delphi
问题描述
我正在考虑构建一些可分发的商业应用程序。
大约一年，我一直在使用Access2000。这是我第一次进入面向对象数据库开发的b
。在Pascal和一些C ++中有一个
的背景，我会更喜欢那些
语言，但是VBA做了。 SQL很好。
我相信后端的安全问题以及网络上的数据完整性/ b $ b腐败投诉可能是一个绊脚石
可靠的可分发应用程序？我也对
无法制作真正编译的可执行.exe前端感到沮丧。我最近读了一些关于Delphi的内容，这似乎涵盖了这些问题，
但是我确信Delphi可能有自己的问题。
我应该使用Access on Jet或SQL构建可销售的应用程序，还是使用Delphi on
Jet或SQL，或其他动物来解决我的问题???
（（（以下评论是我发现的其他评论，而b / b
研究我的想法）））
访问是一个很好的工具来敲门快速简化的应用程序。
但是试图让任何远程复杂的工作都很痛苦。任何
的时间我已经尝试做任何远程复杂的访问我已经发现自己正在解决它的怪癖或不情愿地陷入困境。
它的局限性。
Delphi与访问
a）部署更容易 - 也更便宜 - 没有
每个系统所需的每个座位许可证
您部署到的
。您不必使用链接表来玩
技巧来从数据中分离
代码/表单。
b）Delphi不会''引导您进入Access
运行时及其约束。
- 表单/控件更灵活
- 主题
- 访问Windows
您可以在
Delphi中控制整个应用程序，但是使用Access时，您的规则仍然坚持
。 br />
c）Delphi中的代码管理更简单。你
选择如何将代码分解为单独的
单位/文件。 Access希望
中的所有内容都停留在数据库中。
d）Object Pascal是一种结构化的，更高级别的语言
比作为Access的chimaera / VBA。
e）当涉及到
第三方控件或滚动你的
控件时，Delphi相当好。
I am considering building some distributable commercial applications.
For about a year now, I have been using Access2000. This was my first
venture into object oriented database development. Having a
background in Pascal and some C++, I would have preferred those
languages, but VBA made do. The SQL was fine.
I believe that Security issues on the backend, and data integrity/
corruption complaints over the network may be a stumbling block to a
solid distributable application? I am also discouraged by the
inability to make a truly compiled executable .exe front end. I have
recently read a bit about Delp that seems to cover these issues,
but am sure that Delphi may have its own share of issues.
Should I build marketable apps with Access on Jet or SQL, or Delphi on
Jet or SQL, or some other animal that addresses my concerns???
(((The following comments are those of others I found while
researching my thoughts)))
Access is a great tool for knocking up quick simplistic applications.
But trying to get anything remotely complicated working is a pain. Any
time I''ve tried to do anything remotely complicated with Access I''ve
found myself working around its quirks or falling in reluctantly with
its limitations.
Delphi Vs Access
a) Deployment is easier - and cheaper - no
per seat licenses required on each system
you deploy to. You don''t have to play
tricks with linked tables to separate
code/forms from the data.
b) Delphi doesn''t tie you into the Access
runtime and its constraints.
- forms/controls more flexible
- threads
- access to Windows
You can control the whole application in
Delphi but with Access you''re stuck with
its rules.
c) Code management in Delphi is simpler. You
choose how to break down code into separate
units/files. Access wants everything in
stuck in the database.
d) Object Pascal is a structured, higher level language
than the chimaera that is Access/VBA.
e) Delphi is rather better when it comes to
third party controls or rolling your on
controls.
推荐答案
穿插的评论......
Ap ****** @ gmail.com 写道：
Comments interspersed...
Ap******@gmail.com wrote:
我正在考虑建立一些可分发的商业应用程序。
大约一年了，我一直在使用Access2000。这是我第一次进入面向对象数据库开发的b
。在Pascal和一些C ++中有一个
的背景，我会更喜欢那些
语言，但是VBA做了。 SQL很好。
我相信后端的安全问题以及网络上的数据完整性/ b $ b腐败投诉可能是一个绊脚石
可靠的可分发应用程序？我也对
无法制作真正编译的可执行.exe前端感到沮丧。我最近读了一些关于Delphi的内容，这似乎涵盖了这些问题，
但是我确信Delphi可能有自己的问题。
I am considering building some distributable commercial applications.
For about a year now, I have been using Access2000. This was my first
venture into object oriented database development. Having a
background in Pascal and some C++, I would have preferred those
languages, but VBA made do. The SQL was fine.
I believe that Security issues on the backend, and data integrity/
corruption complaints over the network may be a stumbling block to a
solid distributable application? I am also discouraged by the
inability to make a truly compiled executable .exe front end. I have
recently read a bit about Delp that seems to cover these issues,
but am sure that Delphi may have its own share of issues.
Delphi是一个很好的前端*开发工具*。您仍然需要
a数据库，您将使用哪些易于分发，免费且简单的安装，这将不会出现Access / Jet的安全问题？
Delphi is a good solid development tool *for the front end*. You still need
a database and what will you use that is easy to distribute, free, and easy
to install that will not have the security issues that Access/Jet will?
我应该使用Access on Jet或SQL，还是Delphi on
Jet或SQL，或其他一些解决我的问题的动物构建适销对路的应用程序关注???
Should I build marketable apps with Access on Jet or SQL, or Delphi on
Jet or SQL, or some other animal that addresses my concerns???
（（（以下评论是我发现的其他评论，而b / b研究我的想法））） >
访问是一个很好的工具，用于敲击快速简单的应用程序。
但是试图让任何远程复杂的工作都很痛苦。任何
的时间我已经尝试做任何远程复杂的访问我已经发现自己正在解决它的怪癖或不情愿地陷入困境。
其局限性。
(((The following comments are those of others I found while
researching my thoughts)))
Access is a great tool for knocking up quick simplistic applications.
But trying to get anything remotely complicated working is a pain. Any
time I''ve tried to do anything remotely complicated with Access I''ve
found myself working around its quirks or falling in reluctantly with
its limitations.
绝对垃圾。坏木匠责怪这里的工具。
Absolute rubbish. Bad carpenter blaming the tools here.
Delphi Vs Access
a）部署更简单 - 更便宜 - 没有
每个系统所需的每个座位许可证
您部署到的
。
Delphi Vs Access
a) Deployment is easier - and cheaper - no
per seat licenses required on each system
you deploy to.
是的，但是运行时会解决这个问题。
True, but the runtime would resolve that.
你不必玩
使用链表来欺骗数据中的
代码/表单。
You don''t have to play
tricks with linked tables to separate
code/forms from the data.
我不知道这意味着什么。大多数严重的Access应用程序都有与应用程序其余部分分开的数据
。这不涉及玩'/ b $ b技巧'。不仅仅是连接到任何数据库引擎。
I have no idea what this means. Most any serious Access app has the data
separate from the rest of the application. This does not involve "playing
tricks" any more than connecting to any database engine does.
b）Delphi不会将你绑定到Access
运行时及其约束。
b) Delphi doesn''t tie you into the Access
runtime and its constraints.
有什么限制？
What constraints?
- 表格/控件更灵活
- 线程
- 访问Windows
- forms/controls more flexible
- threads
- access to Windows
1& 2也许，但访问Windows？完整的API可以从
访问。
1 & 2 perhaps, but "access to Windows"? The full API is available from
Access.
您可以在
Delphi中控制整个应用程序，但是访问你坚持使用
其规则。
You can control the whole application in
Delphi but with Access you''re stuck with
its rules.
不知道这意味着什么。任何时候你想为自己创造更多的工作
并离开Access通常如何工作你完全可以自由地这样做
当你这样做时你可以做什么你可以在任何其他
环境中做的任何事情。
No idea what this means. Any time you want to create more work for yourself
and depart from how Access normally works you are completely free to do so
and when you do you shoudl be able to do anything you could do in any other
environment.
c）Delphi中的代码管理更简单。你
选择如何将代码分解为单独的
单位/文件。 Access希望
中的所有内容都卡在数据库中。
c) Code management in Delphi is simpler. You
choose how to break down code into separate
units/files. Access wants everything in
stuck in the database.
见上文。您几乎总是将应用程序部分与数据部分分开
，您也可以使用外部代码库。
See above. You almost always separate the app portion from the data portion
and you can make use of external code libraries as well.
d）Object Pascal是一种结构化的，更高级别的语言
比访问/ VBA的chimaera。
d) Object Pascal is a structured, higher level language
than the chimaera that is Access/VBA.
很大程度上是一个意见问题，但我会承认Pascal
更像是一个真实的一般观点。在那些深奥的区域编程langauage
强硬编码员会关心。更合理的问题虽然
将是它可以完成我需要它做的工作吗？。我从来没有遇到过任何我想在VBA中做的事情我无法以某种方式完成。
Largely a matter of opinion, but I''ll concede the general point that Pascal
is more like a "real" programming langauage in those esoteric areas that
hard-line coders would care about. The more legitimate question though
would be "Can it do the job I need it to do?". I have never encountered
anything I wanted to do in VBA that I could not get done one way or another.
e）Delphi相当更好的说来
第三方控制或滚动你的
控制。
e) Delphi is rather better when it comes to
third party controls or rolling your on
controls.
在这一个肯定。但是，这是否让我失去了一些我需要的东西。或者只是花里胡哨的东西？
这些决定的底线是你上面提到的所有东西
应该占决定的1％你已经熟悉了两个环境之一的
而不是另一个环境。学习
你不熟悉的开支将完全破坏可能存在的所有优点
。
-
Rick Brandt，Microsoft Access MVP
电子邮件（视情况而定）至...
来自Hunter dot com的RBrandt />
For sure in this one. Again though, is this depriving me of something I
"need" or just bells and whistles stuff?
Bottom line with these decisions is that ALL of the stuff you mention above
should account for 1% of the decision if you are already fluent in one of
the two environments and not in the other. The expenditure of learning the
one you are NOT familiar with will totally destroy all of the advantages
that might have been there.
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
问候，
Access是一个很棒的桌面数据库工具 - 适用于小型项目。
注意：访问/ VBA不是面向对象的 - 访问/ VBA是/ b
是从面向对象的语言创建的，但不具备任何OOP
功能，如继承，多态，重载，覆盖。
Delphi，Java，VB.Net，C＃都是面向对象的，所有的多平台都是b $ b（windows，Linux） ， 苹果电脑）。我的大部分工作目前都是使用
Microsoft Sql Server Access。我使用的语言是VB.Net2005，
C＃，Java。对于直接的客户端/服务器前端/后端
应用程序我发现VB2005是最容易使用的语言/平台因为
它完全是OOP并且保留了Visual Basic的易用性。我有从未使用Delphi的
，所以我不能说它，但是.Net是一个副本
的Java，更容易使用混合（这将是微软的一部分）。
我赞成.Net而不是Java，因为它更容易使用。在很多事情中，.Net已经完成了VBA - 有一件事就是减少I / O.您可以在内存中执行大部分数据处理，从而将磁盘读取/写入减少70％以上。这样可以提高性能，减少数据库问题的损坏。对于你写的每行代码
（在VB2005中），在VBA中需要更多行代码 - 主要用于
变通办法 - 绕过OOP中的东西只会取一行
代码。
Ex：
这是一个用于循环文本框集合的VB2005示例：
Dim txtt（）As TextBox = New TextBox（）{txt1，txt2，txt3，txt4}
For each txt As textBox in txttt：Debug.Write （txt.Text）：下一步
这与VBA中的相同（对于Access）
Dim txtt As Variant，txt As Variant
txtt =数组（txt1，txt2，txt3，txt4）
For each txt in txtt：Debug.Print txt：Next
VB2005样本需要2行代码和1个变量（以及其他
变量 - txt - 内联声明）。 VBA采用3行代码和2
变量声明。你可以节省编码的实际成本。
VB.Net是你可以使用代理人为事件分配函数：
For each txt As TextBox in txtt
AddHandler txt.Click，AddressOf someFunction
下一页
假设您在表单上有20个文本框，并且需要一些内容发生在
每个文本框的点击事件。在VB.Net中，您将Click
函数分配给一个循环中的所有文本框。在VBA中你需要
写出每个文本框点击事件来做同样的事情。
3行代码与60行代码。这是OOP编码和无OOP编码之间的巨大差异之一
。
其中Access仍然是超级冠军，因为你
不必加载Visual Studio及其所有开销。访问是一个
自包含数据库编程平台，用于桌面数据库
系统。
我喜欢.Net主要是因为我非常熟悉它，一旦掌握了OOP编码，它就比VBA更容易使用了。
Rich
***通过开发人员指南 http://www.developersdex.com 发送***
Greetings,
Access is a great desktop database tool - for small projects.
note: Access/VBA is/are not object oriented - Access/VBA was/were
created from objected oriented languages, but do not possess any OOP
capabilities like inheritance, polymorphism, overloading, overriding.
Delp Java, VB.Net, C#, are all object oriented and all multi-platform
(windows, Linux, Mac). The majority of my work is currently with
Microsoft Sql Server Access. The languages I have used are VB.Net2005,
C#, Java. For straight forward client/server frontend/backend
applications I find VB2005 the easiest language/platform to use because
it is fully OOP and retains the ease of use of Visual Basic. I have
never used Delp so I can''t say anything about it, but .Net is a copy
of Java with a little more ease of use mixed in (that would be the
Microsoft part).
I favor .Net over Java because it is just easier to use. Of the many
big things .Net has done over VBA - one thing is reducing I/O. You can
do most of the data processing in memory, thus reducing disk
reads/writes by over 70%. This yields way more performance, way less
corruption of databases issues. And for every line of code you write
(in VB2005) it would take more lines of code in VBA - mostly for
workarounds - getting around stuff that in OOP would only take one line
of code.
Ex:
Here is a VB2005 sample for looping through a collection of textboxes:
Dim txtt() As TextBox = New TextBox(){txt1,txt2,txt3,txt4}
For Each txt As TextBox in txttt:Debug.Write(txt.Text):Next
Here is the same thing in VBA (for Access)
Dim txtt As Variant, txt As Variant
txtt = Array(txt1,txt2,txt3,txt4)
For Each txt In txtt:Debug.Print txt: Next
The VB2005 sample took 2 lines of code and 1 variable (well the other
variable - txt - was declared inline). VBA took 3 lines of code and 2
Variable declarations. Where you get the real savings in coding in
VB.Net is that you can use delegates to assign functions to events:
For Each txt As TextBox in txtt
AddHandler txt.Click, AddressOf someFunction
Next
Say you have 20 textboxes on a form and you need something to happen on
the click event of each textbox. In VB.Net you assign the Click
function to all the textboxes in the one loop. In VBA you would have to
write out each textbox click event to do the same thing.
3 lines of code vs 60 lines of code. This is one of the big differences
between OOP coding and None-OOP coding.
Where Access is still the super champ is in small projects because you
don''t have to load up Visual Studio and all its overhead. Access is a
self contained database programming platform for desktop database
systems.
I like .Net mostly because I am very familiar with it, and it is way
easier to use than VBA once you have a handle on OOP coding.
Rich
*** Sent via Developersdex http://www.developersdex.com ***
感谢您的好评！
Thanks for the Great Feedback!
我相信安全问题在后端发生，数据完整性/
网络上的腐败投诉可能是
固态可分发应用程序的绊脚石？我也对
无法制作真正编译的可执行.exe前端感到沮丧。我最近读了一些关于Delphi的b $ b，这似乎涵盖了这些问题，
但是我确信Delphi可能有自己的一些问题。
应该我使用Jet on Jet或SQL构建可销售的应用程序，或者使用Jet或SQL上的Delphi，或其他一些解决我的问题的动物？
I believe that Security issues on the backend, and data integrity/
corruption complaints over the network may be a stumbling block to a
solid distributable application? I am also discouraged by the
inability to make a truly compiled executable .exe front end. I have
recently read a bit about Delp that seems to cover these issues,
but am sure that Delphi may have its own share of issues.
Should I build marketable apps with Access on Jet or SQL, or Delphi on
Jet or SQL, or some other animal that addresses my concerns???
> Delphi是一个很好的前端*开发工具*。您仍然需要一个数据库，您将使用哪些易于分发，免费且易于安装，而不会出现Access / Jet的安全问题？
>Delphi is a good solid development tool *for the front end*. You still need
a database and what will you use that is easy to distribute, free, and easy
to install that will not have the security issues that Access/Jet will?
这是问题???
That IS the Question ???
>>我喜欢.Net主要是因为我对它非常熟悉，而且一旦掌握了OOP编码，它就比VBA更容易使用。
>>I like .Net mostly because I am very familiar with it, and it is way
easier to use than VBA once you have a handle on OOP coding.
我对.Net知之甚少。这会解决我描述的问题吗？
I know little of .Net. Would this resolve the issues I describe???
这篇关于可分发的商业应用访问与德尔福的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
