Distributable Commercial Apps Access Vs Delphi

[ApexData]

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 Delphi, 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.

[Rick Brandt]

Comments interspersed...

Ap******@gmail.com wrote:

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 Delphi, that seems to cover these issues,
but am sure that Delphi may have its own share of issues.

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?

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.

Absolute rubbish. Bad carpenter blaming the tools here.

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.

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 doesn't tie you into the Access
runtime and its constraints.

What constraints?

- forms/controls more flexible
- threads
- access to Windows

1 & 2 perhaps, but "access to Windows"? The full API is available from
Access.

You can control the whole application in
Delphi but with Access you're stuck with
its rules.

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) 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 is a structured, higher level language
than the chimaera that is Access/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 is rather better when it comes to
third party controls or rolling your on
controls.

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

[Rich P]

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.

Delphi, 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 Delphi, 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 ***

[ApexData]

Thanks for the Great Feedback!

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 Delphi, 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 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 ???

>>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.

I know little of .Net. Would this resolve the issues I describe???

[Rich P]

The logic goes like this:

Microsoft creates stuff that is supposed to be easy to use so that
everyone will buy it. VBA is easy to use, but since it is a high level
language (has lots of stuff prebuilt into it) you lose a lot of control.
So when projects become more complex and sophisticated, a high level
language like VBA will become inadequate. For what it is - VBA is quite
sophisticated, but it just can't compete with OOP based platforms.

The newer platform, .Net, also created by Microsoft, overcomes the
inadequacies of VBA by introducing OOP where it previously did not exist
(VB2005). So you still have the ease of use of VB with the robustness
and functionality of OOP. VB.Net is way easier to learn than Java (or
C# to some degree), but the beauty is that you still have (almost) pure
VB (almost no {} brackets to worry about, and there are no ; semicolons
at all to deal with). And VB.Net supports every object supported by C#.

C#
TextBox txt = TextBox1;
txt.Text = "Hello World";

VB.Net
Dim txt As TextBox = TextBox1
txt.Text = "Hello World"

For large scale/multi tiered projects, that are mostly windows based,
..Net is a definite contender.
Rich

*** Sent via Developersdex http://www.developersdex.com ***

[rkc]

Rich P wrote:

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.

So you use a lot of inheritance, polymorphism, overloading, overriding
in your .net applications do you?

Like what for example?

[Rich P]

dim txtt() As TextBox = New TextBox(){txt1, txt2, txt3}

inherits from winform.Textbox class

For Each txt As TextBox In txtt
AddHandler txt.Click, AddressOf somefunction
Next

the txtt array has inherited all the winform.TextBox class properties
and methods.

Rich

*** Sent via Developersdex http://www.developersdex.com ***

[Larry Linson]

<Ap******@gmail.comwrote

Your question is like trying to compare Apples versus Oranges, Apex.

Access is a database development tool; Delphi is a general programming
language. If you are into object-oriented design, development, and
implementation, you ought to be comparing Delphi to other programming
languages, like C, C++, and the DotNet languages. Delphi is Pascal-based,
so in large part, your choice may be whether you prefer Pascal to the C++,
or other "paradigms". You don't seem overly fond of Basic, but those who
are have an even wider range, because they can, in addition to the OO
languages, choose from software tools such as REALBasic and PowerBasic.

Even if you do use a general programming language, as Rick pointed out, you
still need _some_ database, because programming languages don't include one,
as Access includes Jet by default, but supports other database engines,
including servers, in various ways.

BTW, the Access 2007 runtime support (not yet available) will be free for
the download, so that's one issue that's solved if you move to Access 2007.

Larry Linson
Microsoft Access MVP

[John Mishefske]

Ap******@gmail.com wrote:

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 Delphi, 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???

Apex - here's another opinion fwiw...

Someone mentioned that if you go with Delphi you'll still need a database and that's true.
The real question is do you want to use Access and VBA to design the UI.

Lot depends on your target audience. If you know they have Access installed then perhaps
Access/VBA is one possible solution. If the target PCs don't have Access then you'd need
to use the Runtime and I'd recommend that you avoid that.

Distribution using the Runtime is more complex although, if you have the $$, I hear
SageKey makes distributing the Runtime less support-intensive.

You could use an Access .mdb database to store the data without the need to distribute the
Runtime version to users who don't have Access installed (although you may need to include
the MDAC package in your installer to get the appropriate support code to use with the
..mdb from code). So the .mdb database is one way to store persistent data. If you don't
use Access you'll need to find another way to store the data. If you need to support a
large number of users or performance is crucial then SQL Server may be appropriate. If you
are developing "on the cheap" you could look into open source databases like mySQL or
PostgreSQL.

I haven't used Delphi; if you have experience with that then perhaps that's a better
choice. But it sounds like your VBA experience would make a move to VB.Net a better
choice. While substantially different from Access/VBA, it still has a lot of similarities
that will ensure your are developing solutions faster than a switch to a different
language. And, of course, you can create an executable file.

The vb.net compiler is part of the freely downloadable .Net framework so you can create
(simple) apps with that but the VB.Net 2005 IDE will make you much more productive.

But this is a generalization; a lot depends on your application requirements, your budget
and other factors. Good luck.

--
'---------------
'John Mishefske
'---------------

[Albert D. Kallal]

>

For Each txt As TextBox in txtt
AddHandler txt.Click, AddressOf someFunction
Next

In ms-access, you simply assign the function name as follows:

For Each txt in "some collection"
txt.Onclick = "=SomeFunctionName"
next

>
3 lines of code vs 60 lines of code. This is one of the big differences
between OOP coding and None-OOP coding.

Well, actually..it only 3 lines in ms-access also...

And, I should point out this feature/fact has nothing to do with a oo vs non
oo environment. The only
difference is that you have a syntax that lets you assign code to a event
for a control. As mentioned, in ms-access, you can assign the function name
as a expression to the on-click property..and you DO NOT have to open up
the code editor and enter code for each click event (as this example shows).

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

It still takes a ton of MORE work to build things that edit and
display data. Take a look at these screens:

http://www.members.shaw.ca/AlbertKal...icles/Grid.htm

the .net is missing continues forms..and thus you have to resort to complex
coding as compared to simply drag and drop building of forms. (there is some
data repeater controls for .net..but, it takes code).

Further, there is no equivalent of sub-forms, and again that is a huge
design
advantage. For example, I can display related table data, and build a
re-useable form that I drop into ANY form that displays the related customer
data. This approach takes NO code. In the .net environment, again you have
no
equivalent. You can see some examples of sub-forms here as to what I mean:

http://www.members.shaw.ca/AlbertKal...000000005.html
And, data bound forms have huge number of events (for example, a form load
has two events - on-open, and on-load... (the first event allows the form
load to be cancelled based on information in the forms controls). And, if we
cancel, then form never displays. In .net, you only have the .load event,
and can't cancel a form load. You only ability is to pull the code out
of the form, and have the *calling* code test for cases in which the form
should not load..and that is a pain (the code that checks for a legal form
load
belongs with the form).

And, we have multiple updates events also (before update, after update),
for delete events...we have many more events (before del confirm, after del
confirm, on delete).

If you need to write a game, or need a rich interface, then .net is the way
to go. However, if you just need a line of business application, and need to
edit data...ms-access still run circles around vb.net.

And, you not mentioned the report writer...one of the best in the business.

And, if you look at the new forms designer in a2007, we have anchoring of
controls, and even the ribbon bar gives us "stacked", and "tabular"
arranging of our controls. These handy new features make the forms developer
much more productive then previous versions. And, we can use xml mark-up to
create custom ribbon bars now.

And, while we don't have a true OO environment, we can create class
objects....it not that bad....

Without question, I sure you can come up with some things in .net that are
simply better, and easier then ms-access to accomplish. The new data binding
abilities of the .net environment go a LONG way to helping developers.
However, for the majority of data management systems, ms-access is rather
impressive tool, and IMHO still top dog when it comes to productively and
rapid application design (RAD).

The .net environment is a greater development system, and allows one to
build a FAR more rich interface then ms-access. - no debate here. the
problem is that most applcaitons don't need that rich interface. (and, if
they do..then .net becomes a good choice).

And, .net really shines when you start to include web services and
connectivity. the .net environment is "the" killer development system...but,
it just depends on the type of application you are building. for example, if
you have a "team" working on large project, then the OO desing approach is
going to yeild dividends. (we have souce code contorl for ms-access...but,
really, if your project is larger then one person to deveop..then you have
to question if ms-access is the right tool).

Further, when you start involving a server into this mix..then again .net
start to shine even more. I can honestly say that I *really* did wait for 10
years to see the day when the sql server can consume CLR (assemblies) from
..net. This one of controversial features of the new sql server, but I love
the concept!!!

Without question, some projects overlap in terms of what tool to use. In
those cases, I likely use ms-access, and you use .net...because that is what
you know best....

This much comes down to the right horse for the right course..and also what
tools you know best...

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com

[rkc]

Ap******@gmail.com wrote:

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.

My dream distributable commercial application would be a hosted
web application where the server and network problems were worried
about by a third party (we'll call them a partner or maybe associate)
and all I had to do was write the application and collect the
subscription fees. Actually there'd be nothing to distribute except a
license to use it. I'd use whatever tool(s) I could manage to develop
it. That would be cool.

[Rick Brandt]

John Mishefske wrote:
[snip]

Distribution using the Runtime is more complex although, if you have
the $$, I hear SageKey makes distributing the Runtime less
support-intensive.

[snip]

I don't know if the newer versions of the runtime and runtime distribution
package are worse in this regard than Access 97, but if not the emphasis on this
area puzzles me.

I have distributed a handful of runtime apps to a user group numbering in the
low to mid hundreds for about 8 years now and not one time have I had problems
that could be attributed to using the runtime.

The main key to successfully using the runtime is to NOT install it on PCs that
already have Access installed. If you adhere to that rule then there really are
no significant problems.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[John Mishefske]

Rick Brandt wrote:

John Mishefske wrote:
[snip]

>>Distribution using the Runtime is more complex although, if you have
the $$, I hear SageKey makes distributing the Runtime less
support-intensive.

[snip]

I don't know if the newer versions of the runtime and runtime distribution
package are worse in this regard than Access 97, but if not the emphasis on this
area puzzles me.

I have distributed a handful of runtime apps to a user group numbering in the
low to mid hundreds for about 8 years now and not one time have I had problems
that could be attributed to using the runtime.

The main key to successfully using the runtime is to NOT install it on PCs that
already have Access installed. If you adhere to that rule then there really are
no significant problems.

Well I've done the same but found the extra work of having the installer determine if the
user had the runtime version or the full version, the additional size of the installation
distribution package and effort needed to upgrade an existing runtime installation to be
too much extra work.

Might not be an issue for a one-off app though.

I'm making my life easier avoiding runtime distribution as much as possible though I too
have not looked at the (now free) 2007 runtime environment so take my comments fwiw.

--
'---------------
' John Mishefske
'---------------

[ApexData]

ThankYou all for the Great Comments:

Larry Linson
BTW, the Access 2007 runtime support (not yet available) will be free for
the download, so that's one issue that's solved if you move to Access 2007.

Albert Kallal
the .net is missing continues forms..and thus you have to resort to complex
coding as compared to simply drag and drop building of forms.
Further, there is no equivalent of sub-forms, and again that is a huge
design advantage. For example, I can display related table data, and build a
re-useable form that I drop into ANY form that displays the related customer
data. This approach takes NO code. In the .net environment, again you have
no equivalent.

Larry and Albert made comments that stand out in my mind. I was
leaning toward .Net, and I guess I will look into it just to get an
idea of what it is all about. But, maybe the 2007 (Free) runtime
support will be what it takes to stay the course. Unless, the Runtime
conflict issues mentioned become a problem. MS needs to address this,
if it does in-fact exist! Also, I was thinking about Access on the FE
and SQL Server (some variation) on the BE for data security. But, I'm
not sure if that combination will play well with the Runtime???

ThankYou all for the Great Comments:
Greg

** RunTime Problems:

The main key to successfully using the runtime is to NOT install it on PCs that
already have Access installed. If you adhere to that rule then there really are
no significant problems.

I'm making my life easier avoiding runtime distribution as much as possible though I too have not looked at the (now free) 2007 runtime environment so take my
comments fwiw.

[Larry Linson]

<Ap******@gmail.comwrote

Also, I was thinking about Access on the FE
and SQL Server (some variation) on the BE
for data security. But, I'm not sure if that combi-
nation will play well with the Runtime???

As the Access 2007 runtime is not available, it is impossible to say with
certainty that something has not been broken. But, if it has, then I would
expect it to be corrected forthwith and posthaste. In the past, this has
worked just fine.

In the past, and I see no reason to expect otherwise now, the runtime has
been full Microsoft Access with internal flags set to block design view and
design functions. Some were a little surprised to discover the extent of
what Microsoft considered to be design functions, like the ability to apply
filters from the toolbar.

And, in my Access-client to server DB work, I have worked more with other
ODBC-compliant server DBs than with Microsoft SQL Server. That, too, worked
very well.

As some have mentioned, using a third-party install software package and the
SageKey scripts has saved many people a lot of grief in distributing Access
DBs with the runtime. And, considering the savings over installing Office
Pro on the desktop of every user of an Access DB application, it wasn't
cost-prohibitive if you had even a modest number of users.

But, in fact, I never distributed an application with the runtime; I only
used it to demo to my user group. All my clients put full Office Pro on the
machines of each user of the application*, and found it beneficial for them
to have Access for other purposes.

* not necessarily every computer user in their organization,
however.

Larry Linson
Microsoft Access MVP