"Ken Ismert" <kismert@texassystems.com> wrote in message
news:1105552076.931909.257430@f14g2000cwb.googlegr oups.com...
[color=blue]
> Access is billed as RAD, but, in my experience, it is a net gain only
> for simple projects where professional results are not required.[/color]
That is not a fair statement at all.
What exactly do you mean by professional results?
The worst, and I repeat the worst applications I have seen over the
years have been applications written in VB, and not ms-access.
As for seeing poorly designed VB.net applications, the
sample applies. The VB.net applications custom written
for small business that I seen been just terrible.
And, a few other projects I know of failed!!!
Professional results are that of having good designs, and good
developers, and yes, good tools. Ms-access has been around
for a very long time indeed, and has the VB6 IDE and
programming language. It would be silly to say that VB6, or
ms-access somehow does not produce professional results, but
somehow vb.net does? That is a statement of ignorance.
Ms-access is not a OO environment, but is most
laughable that you stand here and tell me that professional
results are harder to obtain in ms-access then that of VB.net.
Why is this so? For what reason?
I am going on the record and telling you it is the reverse!!! Results and
lack of consistency is MUCH worse in VB.net then it is in ms-access.
If you give me two poorly written applications, one in ms-access, and one in
VB.net, the one in VB.net is MUCH WORSE!! I repeat, MUCH
worse!!
Take a well written business crud application written in VB.net, and
that of one in ms-access, and users will find little, if any differences in
terms of useable, or "professionalism" as you state.
The main reason for this (and my experience as consultant) bears this out is
that the vb.net forms model does not have the consistence of how to
approach and solve problems. So, you get one form with different navigation
then the next form. You get one form with navigation buttons, but now
in a different place.
You get one form that saves data in a different way then the next. In
ms-access the forms model for DATA editing is already designed
for you. Thus, a new developer, or a professional developer gets
the same consistency throughout the application.
Now, fair is fair, if your developers are not consistent, then we likely
should not blame the tools. However, this concept applies to vb.net,
assembler, or ms-access. However, for editing data, ms-access does have a
consistent design approach, and vb.net does not. The fact still remains that
you get a more consistent design in ms-access then you do in vb.net
when it comes to editing of data.
If your developers adopt some approach, there is nothing to say that the
next person who comes along will not change how a form works. Again,
in ms-access you can make a mess of data updating, but at least there is a
proper way to use the built in events and how the form works. You
simply can not ignore that this results in a more consistent design, and
further more consistent design among DIFFERENT developers in ms-access.
With vb.net, how the UI, and how data is updated is completely at the whim
of the developers. Again, I will admit that this freedom can be good, but
more often then not..it creates a mess.
This is equivalent to saying we
should get rid of sql because it forces developers to work with data
in a consistent way. Sure, it does restrict the developers choice when
you force sql on them..but then the consistent methodology to using sql
pays off in the long run. So, some restrictions and constraining of
developers is a GOOD THING, and you get better results with
these types of restrictions. Consistent data editing and the
forms object model in ms-access is a perfect example of this
concept in action.
If you have good UI for the application, then ms-access is just fine. While
the following article of mine shows screen shots in ms-access, the
information
supplied also applies to any other development tool(s) you choose to use.
http://www.members.shaw.ca/AlbertKal...erFriendly.htm
I see little, or no problems as to why you could not, or do not get
"professional"
results in ms-access.
And, more amazing, is that more and more developers are leaning that a
way cool funky screen is not better then a simple clean data entry screen.
The explosion of the web is showing that a clean simple interface wins
time and time again over that of "too" rich interface loaded up with
all of hidden menus and features anyway.
..
Uses tend to be MORE happy with a clean simple interface.
[color=blue]
> When
> you try to use Access to deliver a professional quality application,
> the effort required approaches, and may surpass, the effort required to
> deliver a similar result in .Net.[/color]
It is not even close. As I mentioned, that factor of 3 times was
conservative.
[color=blue]
> Take the form event model, for instance. It
> is great for quick and dirty work: slather a bunch of code in there,
> and you're up and running fairly quickly. However, time and time again,
> I find that debugging form events takes up a major amount of my ongoing
> testing budget.[/color]
I can only say that your developers likely did not take the time to learn
the
forms event model. This is the same old story of developers blaming their
tools, and lack of knowledge.
I for example can't believe the number of developers that don't know
when to use on-load vs on-open event. These two events are very important
in ms-access, and how they are used. And, further, having two events for
loading a form also gives one more consistent development approach to
solving TYPICAL problems that crud business applications have.
For example, the on-open of a form is used to test conditions, and certain
things that would CANCEL the form load. Thus, things like record locking
and other conditions can be checked here. And, by the way, even vb.net
does not have a separate on-load vs on-open event to use!!
Once the all of the conditions are meet in the on-open, then all of the
setup code, var initializing etc occurs in the forms on-load event.
What a brilliant concept ms-access has here. So, in the on-open you
can look at, and examine a text box control and recordset data, but it
is too soon to modify the data. You have to use the on-load to do this!
Now, why is this a big deal?
Well, two reasons:
1), a ms-access developer will know that all code that checks to *prevent*
the form from lading will in the in on-open event. (where does a vb.net
developer look for this code?? - please do tell me??And, also tell me
how you cancel the form load in the first place??).
This is means that as a developer, you have a better, and finer division of
the process that occurs when a form opens.
2) And, since it is too soon to modify data, then code that sets up
variables, and sets up controls (defaults etc) on the form will HAVE TO be
in the on-load event.
Once again, this means a developer will know WHERE to look
for the code that sets things up for the form. (in the on-load event).
So, the on load event is for code that sets up variables, sets up
control boxes etc.
Again, this is not only a cleaner design then vb.net forms, but you have
two distinct locations for your code that does NOT exist in vb.net.
Question:
In a vb.net application, where will an average developer find the code that
cancels the form load ? This is painful and hard to do!!
And, where will a developer find the code that initializes variables and
controls on the form? (ok, this one is easy: either all over the place,
or even worse, both the code for prevent the form open, and setup
code is going to be in the forms on-load event. Worse, often
a solution is to have the CALLING code that creates the instance of the form
test, and check to prevent the form load (this is horrible development
approach!!). The code belongs with the FORM...not the calling code!!!
.......bad bad vb.net!! ...spank you!!
Two separate events are needed here..and they are missing!!
[color=blue]
>So much so, that my general development strategy has
> been to not use events where possible, and design my own simpler and
> more predictable work-arounds.[/color]
This is a classic developer issues. Are you willing to take more time
to learn the product, or not? Do you trade more understanding for more
developer productivity or not?
I mean, look at all the different types of collections
available in vb.net (hash code, indexed, non-indexed etc, sorted). And,
in addition to all those new collection types, you also have for good
measure a "legacy" collection object that behaves just like
the existing collection object in VB6 (or, ms-access..as I use those
collections a lot!!). You can ignore all these new features of vb.net, and
NOT take the time to learn about the hash-code collection, or
indexed/sorted collection n vb.net, but the end result is less productively
on your part.
This same reasoning applies to using ms-access forms,
and if you don't take the time to learn them..then you don't get
the benefits.
It is only by learning the more complex objects models are you
going to increase your development rate. The same applies to the
forms object model in ms-access (I warned the OP about this
in my other response). Now, while vb.net has a much rich
object model for many of its objects, it DOES NOT have
a forms object that is optimized and designed solely for
editing of data. Thus, you get a much HIGHER developer
productivity WHEN you are writing an application that is
to edit data. If vb.net was better then ms-access for
editing of data, then bb.net would be a CRAPPIE
general development tool saddled with kinds of extra events
and stuff that non data centric applications do not need!!
vb.net would be disaster of a product if it was better
them ms-access to edit data.
[color=blue]
> .Net has a MUCH better development methodology, and vastly superior
> language features, to VBA. (Note that VB.NET, or a subset, may become
> the scripting language for Access in the near future. If so,
> development opportunities in Access will dramatically open).[/color]
The question is how much gains do you get in productivity here? For MOST
business applications, ms-access is far better, and I mentioned runs
ABSOLUTE circles around vb.net.
The widespread adoption of OO
has not really had a huge impact on programmer productivity in most SMALLER
applications. What OO has done has allowed developers to MANAGE
increasingly complex applications with greater ease (read: better for
LARGER
and more complex applications!). The average business is NOT writing Excel,
or
creating a word processor, and thus the benefits of OO don't help very much.
[color=blue]
> So much so that I believe a good component developer in .NET
> could craft a set of flexible, reusable data and form components, based
> on a far simpler event/messaging model than Access forms have, and run
> rings around the average Access developer in terms of productivity.[/color]
Sorry, that is just not the case. And, the projects I seem in both vb.net
and ms-access bear this out. It is just not even close, as much as
many want to believe. I really do wish vb.net was close to ms-access
in this regards. However, our believes, or hopes on this issue does
not change the brutal realty, and facts as they are!
It is like you are telling me in place of using auto-cad to design cad
drawings, that you should use vb.net? This is all about using the right
tools for the right job. vb.net is a GENERAL development platform, and as
such is a incredible development platform. However, just like vb.net is not
for making cad drawings, it is also NOT primary designed to build forms that
edit data (and ms-access is). I am trying hard here to understand what part
of this concept you don't understand here?
You are not nearly as productive to build forms that edit data in vb.net as
you are in ms-access. When products like dbaseII, and FoxPro etc. came out,
they caused a revolution in the pc business because all of a sudden, the
developer productivity to write applications that edits data was on the
order of
magnitude of traditional development tools. It did not make sense back then
to
code an application in a plane Jane BASIC, or c, or c++ language.
Today, we still have a basic programming language for windows, and that is
vb.net. However, this programming system does not compare to the production
that you get with tools designed specially to edit data in forms. Nor, does
it
compare with a CAD system to make drawings. It is not that a developer
using ms-access somehow types faster, it is just that the product is
designed
to do certain tasks better then a general development system like vb.net.
However, there are good number of reasons to use vb.net, (and you pointed
out
a few). I do believe that when the requirement goes beyond one developer, or
budgets exceed that of about $35,000, then vb.net is a better choice. This
is because the development process with larger complexity and a larger code
base needs to scale to using more developers. And, thus the OO approach
of encompassing code and rules then also beings to pay off on projects of
these sizes. You don't need a big huge Mac truck to deliver one small
parcel across town. However, as things get larger, and greater
in size, eventually, you need that big rig to move your stuff. This concept
also applies to vb.net.
The other area where traditional developer platforms is a better choice then
ms-access is in terms of wide spread distribution. If you are distributing
an application to 200,000 users, then you can easily spend $10,000
on just a screen and a grid control to work exactly the way you want. For a
in
house application, you have no such luxury, and likey the WHOLE budject
for the project is going to only $10,000. Further, those general tools have
BETTER package and deplyment tools, and as they should!!
(one of my ms-access applies was competed in less then 3 months, has 160
forms, and about 27,000 lines of code. In vb.net, you can multiply the time
by a factor of 3, or 4, and you get year of time to complete this project.
And, speaking of development advances, I should point out that
ms-access developers for 10 years now have enjoyed x-copy development.
The vb.net community is just now realizing how great of concept this is! On
the
other hand, you do have to hope that the CLR is present on those
machines, and the right one is present. And, of course we assume that
future releases will NOT break your application!!
Just to be clear, I am strong believer in the CLR concept, and the ms-access
model
proves this in practice. All we just have to do is ensure that the right
version of office is installed (for ms-access), or the right CLR, and then
the rest is x-copy. This is real nice!! I don't need to be sold on this
concept,
since we had it for a very long time.
[color=blue]
>
> The only thing that Access has that would be truly hard to replace is
> the report generator, but SQL Server Reporting Services is just good
> enough, and within a few versions, should be more than up to the task.[/color]
Actually, there is a zillion things. For example, how do you open a form to
a invoice record?
strWhatInvovie = inputbox("view what invoice")
docme.OpenForm "frmInvoice",,,"invoiceNum = " & strWhatInvoice
I count 2 lines of code. What is your solution in vb.net. I can really write
on for 100's of pages here.
Still no multi-column combo box, still not combo box with a "not in list
event" (how on earth do you write code to bring up a form to
add ONE new item to the combo box..and continue? We got an
event JUST for this task..."not in list"). And, still no sub-forms,
still no continues forms. (this list is ad-nasm long here). I
simply going to stop here.
vb.net is not auto-cad, nor is vb.net a system to build applications
that are data centric like ms-access is.
I would be crazy to build a game in ms-access, but certainly it DOES
makes sense to write games in vb.net. (some argue that c++ is still better
yet!!).
For a very large portion of in-house business applications, ms-access is a
far
better choice then is vb.net.
I am perfectly willing to admit that for a lot of in-house applications,
vb.net is a better choice then ms-access also!. However, at least I
have taken the time to figure out when the choice between the tools
should be made. If you don't make that choice..you are wasting
lots of money that could go to help other projects..or even
needy people around the world..
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com http://www.members.shaw.ca/AlbertKallal 
