dotnet windows forms vs. Access

You SERIOUSLY haven't looked at continuous forms and subforms if you think
any type of grid control holds a candle to them.


Rob

"Thomas" wrote in message
...
Baz wrote:
I have two things to say to you: linked subforms and continuous forms.

Baz, I don't think this is an Access advantage. For example, look at those
tutorials:
http://msdn.microsoft.com/vstudio/to...taGridView.htm
http://www.devexpress.com/Products/N...idlesson1.html

It's fast to create (at least as fast as Access), it has more features
than Access etc.

This is only one approach - it's similar to Access' one (I don't like any
of them, though). If you need n-tiered application it's better to do the
dynamic grid creation. In both cases you can do it with VS out of the box
or you can buy some 3rd party components.

--


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------

Yep, that sounds like advertising. As I said, I own VS 2003 Professional
and I consider it to have been a complete waste of money. I do not believe
that VS 2005 can be so much better that it is worth me spending any time on
it, and I'm certainly not going to waste any money buying add-ons for it.
I'd rather put my efforts into continuing my investigations into Delphi (not
that I see Delphi as a serious contender to Access either for database
applications, it's just that, for the odd occasion when I do something for
which I don't consider Access suitable, I'd like to have a serious and
current alternative to VB6).

"Thomas" wrote in message
...
Baz, you can use free VS 2005 Express and don't buy any 3rd party
component if you don't want, and you can still produce i.e. continuous
forms with DataGridView component. This is not the best solution but
either is not worse than Access (for which there is no free version at
all).

IMO, a lot of 3rd party components *do* work very well - guys at
Developer Express, ComponentOne, Infragistic etc. really produce very
usable products. Serious developer should at least try them before judge
about their usability or quality. They are also very cheap comparing to
the price of developing only few percent of their features. Maybe it
sounds like advertising but I really just buy them and use them, and I
want to share good experience with other developers.


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------




Baz wrote:
Well I haven't got VS 2005 and I'm not likely to get it either (having
wasted a significant amount of my own money on upgrading from VS 6 to VS
2002/2003, and then concluding that it sucked so badly that I was simply
not
interested in using it).

Nor am I impressed by a product which requires me to buy third-party
add-ons
in order for it to be anywhere near usable.


"Thomas" wrote in message
...
Baz wrote:
I have two things to say to you: linked subforms and continuous forms.
Baz, I don't think this is an Access advantage. For example, look at
those tutorials:


http://msdn.microsoft.com/vstudio/to...taGridView.htm

http://www.devexpress.com/Products/N...idlesson1.html
It's fast to create (at least as fast as Access), it has more features
than Access etc.

This is only one approach - it's similar to Access' one (I don't like
any of them, though). If you need n-tiered application it's better to
do
the dynamic grid creation. In both cases you can do it with VS out of
the box or you can buy some 3rd party components.

--


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------

I'd like to hear some examples where continuous forms outperforms .NET
grids?


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------




Robert Morley wrote:
You SERIOUSLY haven't looked at continuous forms and subforms if you think
any type of grid control holds a candle to them.


Rob

"Thomas" wrote in message
...
Baz wrote:
I have two things to say to you: linked subforms and continuous forms.
Baz, I don't think this is an Access advantage. For example, look at those
tutorials:
http://msdn.microsoft.com/vstudio/to...taGridView.htm
http://www.devexpress.com/Products/N...idlesson1.html

It's fast to create (at least as fast as Access), it has more features
than Access etc.

This is only one approach - it's similar to Access' one (I don't like any
of them, though). If you need n-tiered application it's better to do the
dynamic grid creation. In both cases you can do it with VS out of the box
or you can buy some 3rd party components.

--


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------

I still don't know the reasons you were not satisfied with VS/.NET
(except that with learning time)?


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------




Baz wrote:
Yep, that sounds like advertising. As I said, I own VS 2003 Professional
and I consider it to have been a complete waste of money. I do not believe
that VS 2005 can be so much better that it is worth me spending any time on
it, and I'm certainly not going to waste any money buying add-ons for it.
I'd rather put my efforts into continuing my investigations into Delphi (not
that I see Delphi as a serious contender to Access either for database
applications, it's just that, for the odd occasion when I do something for
which I don't consider Access suitable, I'd like to have a serious and
current alternative to VB6).

"Thomas" wrote in message
...
Baz, you can use free VS 2005 Express and don't buy any 3rd party
component if you don't want, and you can still produce i.e. continuous
forms with DataGridView component. This is not the best solution but
either is not worse than Access (for which there is no free version at
all).

IMO, a lot of 3rd party components *do* work very well - guys at
Developer Express, ComponentOne, Infragistic etc. really produce very
usable products. Serious developer should at least try them before judge
about their usability or quality. They are also very cheap comparing to
the price of developing only few percent of their features. Maybe it
sounds like advertising but I really just buy them and use them, and I
want to share good experience with other developers.


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------




Baz wrote:
Well I haven't got VS 2005 and I'm not likely to get it either (having
wasted a significant amount of my own money on upgrading from VS 6 to VS
2002/2003, and then concluding that it sucked so badly that I was simply
not
interested in using it).

Nor am I impressed by a product which requires me to buy third-party
add-ons
in order for it to be anywhere near usable.


"Thomas" wrote in message
...
Baz wrote:
I have two things to say to you: linked subforms and continuous forms.
Baz, I don't think this is an Access advantage. For example, look at
those tutorials:

http://msdn.microsoft.com/vstudio/to...taGridView.htm
http://www.devexpress.com/Products/N...idlesson1.html
It's fast to create (at least as fast as Access), it has more features
than Access etc.

This is only one approach - it's similar to Access' one (I don't like
any of them, though). If you need n-tiered application it's better to
do
the dynamic grid creation. In both cases you can do it with VS out of
the box or you can buy some 3rd party components.

--


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------

:-)
OK, I can partly agree with you as I prefer the bike, too. Maybe it's
really bad analogy. What about this one (note the "Compared with the
scroll..." sentence):
http://www.youtube.com/watch?v=xFAWR6hzZek

;-)


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------




Robert Morley wrote:
(it's easier to ride bike than drive car, too).

Bad argument to make for me; I'm nearing 40, and I've never driven a car. I
use public transit for everything. About half my friends don't drive,
either, and my partner, who's a professional photographer, uses his bike as
his company vehicle without a problem.

As you say, form or report creating wizards are not of much use.

Actually, it wasn't me that said that, though for the most part, I agree.



Rob

I also think it's not good to use VS/.NET to port your existing
applications but it should be considered when thinking about the new ones.

But you can't argument advantages of one development tool just with
saying that it is better for certain people.

I have a proposal for trying to solve this dilemma: if you have one or
two days in the following month or two, we can imagine simple fictitious
business application (it can be also some usable problem which we can
sell then as a product, too :-)).
You can propose the half of virtual customer's demands, and I will
propose the other half. We can make together a portable database model
which will be the starting point for both of us. You will use Access
while I'll use VS/.NET to build the business application. When both of
us would be ready we can show the movie how did we build the application
and exchange application installer file.
We can use any additional tool and we'll compare the price of all used
tools (including Access and VS). The purpose of this "competition" is to
show both the speed of development and costs of software used. I think
this could be a good test for anyone watching this debate and asking
himself if it's worth to stick with .NET or rather with Access.
What do you think about it?

Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------




Robert Morley wrote:
I think what Larry and I are trying to say is that for us, we find Access to
vastly outperform .NET in terms of development time.

That said, however, it's possible that .NET 2005 can do it, but I, at least,
haven't seen anything to prove that to me concretely, and I'm certainly not
about to spend money, and months or years worth of time porting my existing
business apps in the hopes that their might be some marginal gain to my
ability to develop applications faster. Even if we accept that development
is faster, the additional time/learning curve required easily outweighs any
advantage to .NET.

The performance of VB.NET also has yet to equal that of VB6/VBA, so that is
a consideration as well. The only way to get acceptable performance in many
cases is to use unmanaged code, and I have no ambitions to learn C++.


Rob

"Thomas" wrote in message
...
Larry Linson wrote:
"Thomas" wrote

. . .
I think development was faster with Access only in the early age of
.NET. With .NET you have much greater possibilities to gradually
accumulate really reusable pieces of code or create automated code
generation tools which significantly outperform Access in almost any
aspect.

Ah, Thomas, you said that like a true DotNet bigot. You have, no doubt,
made friends in Redmond with that kind of reply.

I had a C-programmer colleague back at the "major computer manufacturer"
from which I retired who said something similar about C, and then about
C++, comparing it to PL/I, Basic, and then to Visual Basic and Access.
He's likely saying the same about C#, now, but chances are the clients
who can afford him are all doing distributed enterprise apps that are
web-based.

The problem is that you _DO NEED_ to "gradually accumulate" (and
purchase/license -- lots of purchasing/licensing going on in the DotNet
world) reusable pieces of code or create automated code generation tools
in order to do with any facility even the most basic of the database
functions that are built in to Access, right out of the box. That is, if
you re-create Access in DotNet, you'll almost catch up with "the real
thing."

You do realize, don't you, that the statement "significantly outperform
Access in almost any aspect" is essentially content-free, don't you?
Frankly, my view is that "Access out of the box outperforms Visual Studio
in creating normal business database applications for the single-user,
multi-user, anc client-server environments". I know a few people who do
both Access and DotNet, and they agree with me; the ones who don't are
those who don't now use, or perhaps never have used, Access and think
it's just a "junior version" of DotNet.

The essential functionality needed for controlling the application,
navigating, and manipulating the database is ALREADY THERE with Access,
so all you have to do is put in the business functions (and, unless you
develop very similar applications for multiple businesses, it's not going
to be useful, and depending on your agreement with your clients, may not
be legal, to "package" their business functionality as "really reusable
pieces of code".)

I spent some of the early part of my career creating development tools.
It's interesting work, but it's not something an application developer
should have to do in order to get decent development for their investment
of time and effort, or to be able to accomplish what they need at all.
It's a lot more productive for the application developer to develop
applications, not tools, not create and accumulate libraries.

Larry Linson
Microsoft Access MVP



Larry, don't get me wrong. It's really not about being a DotNet fan (and I
believe you can get friends in Redmond speaking friendly about Access,
too). :-)

I do work right now (and was working for several years in the past) both
with Access and .NET, and I'm just comparing both of the worlds.

Speaking about the licensing "problem" - I think we should calculate if
this is really the drawback of the .NET. Most of the components typical
developer needs are royalty free so you have to purchase only one piece of
the license. For example, if you need rich gui components you will spend
about $1000 but you will get very powerful tools which can significantly
shorten development time - for both Windows and Web platform (not to
mention enormous end-user capabilities). The same (or even cheaper) is
with the refactoring or code generation tools etc. Comparing such sums
with the earnings of developer (or company) is insignificant.

So, the question should not be if Access out of the box outperforms Visual
Studio (also out of the box) for some type of applications. I agree it is
probably true if we treat this question only theoretically but in the real
world developer should calculate the whole costs of development. In the
end everybody (at least in my opinion) realize that the only meaningful
cost is the development time.

Therefore I see the only reasonable argument in behalf of Access the
learning curve. Someone should consider if it's worth to spend more time
learning .NET and OO programming, and get the chance to compete also in
the enterprise applications market, or spend less time and stay limited
with the Access capabilities and obsolete programming language.


--


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------

The biggest example that comes to mind is the ability to create
"mini-forms". For example, I have a continuous subform for comments that
has a delete button on it, a few check boxes, and so forth. It's about a 1"
high form with a multi-line text box embedded within it. While in this
case, it's a plain text box, I have the option to make it an RTF editor or
anything else I might want. I'd seriously like to see a grid view that can
handle that kind of form design within it. Nothing even comes close that
I've ever seen. What's more, to do that kind of design work, I don't need
any additional knowledge of the control; my ability to create forms is all I
need to know.

But even looking at a one-line, grid style of form, there's all the
associated form events to consider, which most grids don't support, the
ability to put custom controls, images, command buttons, etc., into your
grid, the ability to disable fields (though some grids may do better in this
regard, since Access can only enable/disable the entire column at a
time...few grids support selective disabling, though, that I've seen).

It's these sorts of things that make me look at things like data grids as
the lesser form of continuous forms. And the ability to embed one form
within another is just as nice. I think you can get the same effect
with...was it panes they called it in .NET?...or using visual inheritance,
but I don't remember it being as easy as dragging and dropping one form on
top of another. I never really got that advanced on .NET, so I'd be content
to have it proven that it's just as easy in .NET as it is in Access.



Rob

"Thomas" wrote in message
...
I'd like to hear some examples where continuous forms outperforms .NET
grids?


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------




Robert Morley wrote:
You SERIOUSLY haven't looked at continuous forms and subforms if you
think any type of grid control holds a candle to them.


Rob

"Thomas" wrote in message
...
Baz wrote:
I have two things to say to you: linked subforms and continuous forms.
Baz, I don't think this is an Access advantage. For example, look at
those tutorials:
http://msdn.microsoft.com/vstudio/to...taGridView.htm
http://www.devexpress.com/Products/N...idlesson1.html

It's fast to create (at least as fast as Access), it has more features
than Access etc.

This is only one approach - it's similar to Access' one (I don't like
any of them, though). If you need n-tiered application it's better to do
the dynamic grid creation. In both cases you can do it with VS out of
the box or you can buy some 3rd party components.

--


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------

It's an interesting idea, but I seriously don't have the time these days.
If you'd asked me over the winter, I might've been able to do it. If
anybody else takes you up on that, though, I'd love to see the results.


Rob

"Thomas" wrote in message
...
I also think it's not good to use VS/.NET to port your existing
applications but it should be considered when thinking about the new ones.

But you can't argument advantages of one development tool just with saying
that it is better for certain people.

I have a proposal for trying to solve this dilemma: if you have one or two
days in the following month or two, we can imagine simple fictitious
business application (it can be also some usable problem which we can sell
then as a product, too :-)).
You can propose the half of virtual customer's demands, and I will propose
the other half. We can make together a portable database model which will
be the starting point for both of us. You will use Access while I'll use
VS/.NET to build the business application. When both of us would be ready
we can show the movie how did we build the application and exchange
application installer file.
We can use any additional tool and we'll compare the price of all used
tools (including Access and VS). The purpose of this "competition" is to
show both the speed of development and costs of software used. I think
this could be a good test for anyone watching this debate and asking
himself if it's worth to stick with .NET or rather with Access.
What do you think about it?

Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------




Robert Morley wrote:
I think what Larry and I are trying to say is that for us, we find Access
to vastly outperform .NET in terms of development time.

That said, however, it's possible that .NET 2005 can do it, but I, at
least, haven't seen anything to prove that to me concretely, and I'm
certainly not about to spend money, and months or years worth of time
porting my existing business apps in the hopes that their might be some
marginal gain to my ability to develop applications faster. Even if we
accept that development is faster, the additional time/learning curve
required easily outweighs any advantage to .NET.

The performance of VB.NET also has yet to equal that of VB6/VBA, so that
is a consideration as well. The only way to get acceptable performance
in many cases is to use unmanaged code, and I have no ambitions to learn
C++.


Rob

"Thomas" wrote in message
...
Larry Linson wrote:
"Thomas" wrote

. . .
I think development was faster with Access only in the early age of
.NET. With .NET you have much greater possibilities to gradually
accumulate really reusable pieces of code or create automated code
generation tools which significantly outperform Access in almost
any aspect.

Ah, Thomas, you said that like a true DotNet bigot. You have, no doubt,
made friends in Redmond with that kind of reply.

I had a C-programmer colleague back at the "major computer
manufacturer" from which I retired who said something similar about C,
and then about C++, comparing it to PL/I, Basic, and then to Visual
Basic and Access. He's likely saying the same about C#, now, but
chances are the clients who can afford him are all doing distributed
enterprise apps that are web-based.

The problem is that you _DO NEED_ to "gradually accumulate" (and
purchase/license -- lots of purchasing/licensing going on in the DotNet
world) reusable pieces of code or create automated code generation
tools in order to do with any facility even the most basic of the
database functions that are built in to Access, right out of the box.
That is, if you re-create Access in DotNet, you'll almost catch up with
"the real thing."

You do realize, don't you, that the statement "significantly outperform
Access in almost any aspect" is essentially content-free, don't you?
Frankly, my view is that "Access out of the box outperforms Visual
Studio in creating normal business database applications for the
single-user, multi-user, anc client-server environments". I know a few
people who do both Access and DotNet, and they agree with me; the ones
who don't are those who don't now use, or perhaps never have used,
Access and think it's just a "junior version" of DotNet.

The essential functionality needed for controlling the application,
navigating, and manipulating the database is ALREADY THERE with Access,
so all you have to do is put in the business functions (and, unless you
develop very similar applications for multiple businesses, it's not
going to be useful, and depending on your agreement with your clients,
may not be legal, to "package" their business functionality as "really
reusable pieces of code".)

I spent some of the early part of my career creating development tools.
It's interesting work, but it's not something an application developer
should have to do in order to get decent development for their
investment of time and effort, or to be able to accomplish what they
need at all. It's a lot more productive for the application developer
to develop applications, not tools, not create and accumulate
libraries.

Larry Linson
Microsoft Access MVP



Larry, don't get me wrong. It's really not about being a DotNet fan (and
I believe you can get friends in Redmond speaking friendly about Access,
too). :-)

I do work right now (and was working for several years in the past) both
with Access and .NET, and I'm just comparing both of the worlds.

Speaking about the licensing "problem" - I think we should calculate if
this is really the drawback of the .NET. Most of the components typical
developer needs are royalty free so you have to purchase only one piece
of the license. For example, if you need rich gui components you will
spend about $1000 but you will get very powerful tools which can
significantly shorten development time - for both Windows and Web
platform (not to mention enormous end-user capabilities). The same (or
even cheaper) is with the refactoring or code generation tools etc.
Comparing such sums with the earnings of developer (or company) is
insignificant.

So, the question should not be if Access out of the box outperforms
Visual Studio (also out of the box) for some type of applications. I
agree it is probably true if we treat this question only theoretically
but in the real world developer should calculate the whole costs of
development. In the end everybody (at least in my opinion) realize that
the only meaningful cost is the development time.

Therefore I see the only reasonable argument in behalf of Access the
learning curve. Someone should consider if it's worth to spend more time
learning .NET and OO programming, and get the chance to compete also in
the enterprise applications market, or spend less time and stay limited
with the Access capabilities and obsolete programming language.


--


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------

Rob, great, winter is quite suitable if nobody else would have time
before that.


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------




Robert Morley wrote:
It's an interesting idea, but I seriously don't have the time these days.
If you'd asked me over the winter, I might've been able to do it. If
anybody else takes you up on that, though, I'd love to see the results.


Rob

"Thomas" wrote in message
...
I also think it's not good to use VS/.NET to port your existing
applications but it should be considered when thinking about the new ones.

But you can't argument advantages of one development tool just with saying
that it is better for certain people.

I have a proposal for trying to solve this dilemma: if you have one or two
days in the following month or two, we can imagine simple fictitious
business application (it can be also some usable problem which we can sell
then as a product, too :-)).
You can propose the half of virtual customer's demands, and I will propose
the other half. We can make together a portable database model which will
be the starting point for both of us. You will use Access while I'll use
VS/.NET to build the business application. When both of us would be ready
we can show the movie how did we build the application and exchange
application installer file.
We can use any additional tool and we'll compare the price of all used
tools (including Access and VS). The purpose of this "competition" is to
show both the speed of development and costs of software used. I think
this could be a good test for anyone watching this debate and asking
himself if it's worth to stick with .NET or rather with Access.
What do you think about it?

Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------




Robert Morley wrote:
I think what Larry and I are trying to say is that for us, we find Access
to vastly outperform .NET in terms of development time.

That said, however, it's possible that .NET 2005 can do it, but I, at
least, haven't seen anything to prove that to me concretely, and I'm
certainly not about to spend money, and months or years worth of time
porting my existing business apps in the hopes that their might be some
marginal gain to my ability to develop applications faster. Even if we
accept that development is faster, the additional time/learning curve
required easily outweighs any advantage to .NET.

The performance of VB.NET also has yet to equal that of VB6/VBA, so that
is a consideration as well. The only way to get acceptable performance
in many cases is to use unmanaged code, and I have no ambitions to learn
C++.


Rob

"Thomas" wrote in message
...
Larry Linson wrote:
"Thomas" wrote

. . .
I think development was faster with Access only in the early age of
.NET. With .NET you have much greater possibilities to gradually
accumulate really reusable pieces of code or create automated code
generation tools which significantly outperform Access in almost
any aspect.

Ah, Thomas, you said that like a true DotNet bigot. You have, no doubt,
made friends in Redmond with that kind of reply.

I had a C-programmer colleague back at the "major computer
manufacturer" from which I retired who said something similar about C,
and then about C++, comparing it to PL/I, Basic, and then to Visual
Basic and Access. He's likely saying the same about C#, now, but
chances are the clients who can afford him are all doing distributed
enterprise apps that are web-based.

The problem is that you _DO NEED_ to "gradually accumulate" (and
purchase/license -- lots of purchasing/licensing going on in the DotNet
world) reusable pieces of code or create automated code generation
tools in order to do with any facility even the most basic of the
database functions that are built in to Access, right out of the box.
That is, if you re-create Access in DotNet, you'll almost catch up with
"the real thing."

You do realize, don't you, that the statement "significantly outperform
Access in almost any aspect" is essentially content-free, don't you?
Frankly, my view is that "Access out of the box outperforms Visual
Studio in creating normal business database applications for the
single-user, multi-user, anc client-server environments". I know a few
people who do both Access and DotNet, and they agree with me; the ones
who don't are those who don't now use, or perhaps never have used,
Access and think it's just a "junior version" of DotNet.

The essential functionality needed for controlling the application,
navigating, and manipulating the database is ALREADY THERE with Access,
so all you have to do is put in the business functions (and, unless you
develop very similar applications for multiple businesses, it's not
going to be useful, and depending on your agreement with your clients,
may not be legal, to "package" their business functionality as "really
reusable pieces of code".)

I spent some of the early part of my career creating development tools.
It's interesting work, but it's not something an application developer
should have to do in order to get decent development for their
investment of time and effort, or to be able to accomplish what they
need at all. It's a lot more productive for the application developer
to develop applications, not tools, not create and accumulate
libraries.

Larry Linson
Microsoft Access MVP



Larry, don't get me wrong. It's really not about being a DotNet fan (and
I believe you can get friends in Redmond speaking friendly about Access,
too). :-)

I do work right now (and was working for several years in the past) both
with Access and .NET, and I'm just comparing both of the worlds.

Speaking about the licensing "problem" - I think we should calculate if
this is really the drawback of the .NET. Most of the components typical
developer needs are royalty free so you have to purchase only one piece
of the license. For example, if you need rich gui components you will
spend about $1000 but you will get very powerful tools which can
significantly shorten development time - for both Windows and Web
platform (not to mention enormous end-user capabilities). The same (or
even cheaper) is with the refactoring or code generation tools etc.
Comparing such sums with the earnings of developer (or company) is
insignificant.

So, the question should not be if Access out of the box outperforms
Visual Studio (also out of the box) for some type of applications. I
agree it is probably true if we treat this question only theoretically
but in the real world developer should calculate the whole costs of
development. In the end everybody (at least in my opinion) realize that
the only meaningful cost is the development time.

Therefore I see the only reasonable argument in behalf of Access the
learning curve. Someone should consider if it's worth to spend more time
learning .NET and OO programming, and get the chance to compete also in
the enterprise applications market, or spend less time and stay limited
with the Access capabilities and obsolete programming language.


--


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------

Thomas wrote:

I have a proposal for trying to solve this dilemma: if you have one or
two days in the following month or two, we can imagine simple fictitious
business application (it can be also some usable problem which we can
sell then as a product, too :-)).

Or how about for a non profit group that has a geniune need for such a solution.

Tony

--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/