Back then I thought Access was a great tool. Now I think it works perfect
for a back-end of smaller apps but front-end... hmm no. I guess it works
perfect if you want to get something together quite fast and few users but
other than that?
It really depends on what data engine you use with ms-access. Really,
ms-access is just a VB development environment with a different forms models
then what you got in VB. The code and syntax in ms-access is the same as VB.
Further, if you use VB, c++, or ms-access to connect to a database, the
performance will NOT be different between these systems. So, there are
companies right not that have 1000 ms-access users all hitting the same
database at the same time. So, ms-access is just a IDE like VB or any other
development product. You build the application in ms-access, but the data
engine you connect to is you choice (Oracle, sql-server, JET, etc).
I would have created this front-end in VB just as fast but
the customer is always right
Hum, if you have experience with both platforms, then you will generally
find ms-access production rates in the range of 2, or 3 times that of VB.
That means a$8000 project in ms-access will eat up $24,000 of VB developer
time. There is little, of any comparing in the productivity of VB
development to ms-access development when talking about data centric
applications.
If you take a look at the following screen shots of some ms-access showing
data, it is interesting to note that you can see in some screen shots a
button that will launch a new form to display he one record. What is
amazing, is that you can open a form in ms-access to a particular invoice,
or part number or whatever with ONE line of code (imagine that...one line
code?). You just don't get that kind of leverage in VB forms.
Look, VB is a great development platform, but it is not a data centric
product. VB thus rather pales as compared to ms-access for projects that
just have to edit data. On the other hand, I would not try and write a
pac-man game in ms-access, but you certainly can and would in VB. So, they
are VERY different tools. VB is a general application development tool, and
not a data centric product. If VB was anywhere near ms-access in terms of
development rate, then ms-access would have been dumped long ago (and, I
would have dumped VB long ago too!).
So, while ms-access shares the same code base and compiler as VB6, and even
the same language syntax as VB, the forms and object model are complete
different from VB.
Developing in Access is kind of strange. In VB I would put whatever
controls
on the form I would need no more no less.
Actually, your vb controls generally need a LOT more! And, the lack of
properties for the VB controls is very problematic for editing of data.
There are differences between the VB concepts of controls, and ms-access
controls (for example, we have both .text, and .value, and .oldvalue...that
is 3 different ways to use values on a control, and they are required for
any kind of decent data entering. In VB...what..you have one (text) property
to deal with? (how simple, and yet this means VB seems easer, but then you
turn around have to write all kinds of code to duplicate what is standard
and so often needed for general editing).
You can view a list of fields in design mode, and simply drag the field from
the field list to the screen,a nd you get a data bound control, *and* even a
label is placed on the screen. For laying out data fields on a screen,
ms-access runs circles around the VB editor. And, what ever happened to
highlighting a field, and then using the duplicate button in VB?
In Access I have to remove a lot
Access functionality that I don't want the user to have. As I said I use
to
be an Access fan but I guess I've grown up
Hum, about all I have to turn off is the record selection, record navigation
, auto re-size. Also, once you setup a control the way you let, you go
format->set contorl defaults, and then everything that follows is the same.
The trick in ms-access, or any development tools is learning what exists,
and the how those features HELP YOU!
For example, access forms have both a on-open event, and a on-load event
(this is sorely missing in VB). What this brilliant dividing means is that
the on-open event (should) has code for verifying tings, or testing for a
conditions that would PREVENT the form from actually loading. You can't do
this in VB, as the form is already loaded and displayed......or you can come
up with some VERY painful workarounds. So, we use the on-open event to test
for a record lock, or perhaps some other criteria that will NOT allow the
form to open. This means the form's on-load event will not occur, and the
form will not display. In vb, you can't do this, since your code to "test"
if the form can be loaded has to be placed outside of the form (and, that is
silly...the code belongs WITH the form). Of course, once the on-open event
does occur, then the more familiar on-load event runs. Obviously, in the
on-load event stuff like setting up variables, setting some defaults, or
even setting values of controls is possible (you can't set the values of
controls in the on-open event...it is too soon). So, not only do we have two
events here (where VB forms has only one), but that divisions means as a
developer you now know were to look for certain kinds of code (verify code
in "open", and setup code in "load"). This kind of division makes the
development process more consistent, and actually easier since now we have a
spot for code that will prevent the form load. In VB, every man comes up
with a complete different approach and solution to this problem..and the
result is a terrible lack of consistency.
The other area where VB forms lack re the data event. We have tons of events
here, on insert, before update, after update, on delete...this list is VERY
long. To duplexes these standard functions that you need on a daily bases
in VB takes REAMS and REAMS of code.
I could write for pages and pages but, simply put, VB is a general tool, not
hot knife through butter when it comes to data centric applications. They
are very different tools, and sure...we all kind of have our "favored"
system, or some system that we are more familiar with...but that changes
little in how ms-access runs circles around VB for data centric projects.
