Which is more efficient and user-friendly: Using forms for the databases through Access or through f

[A Future Computer Scientist]

I'm creating an info tracking database for the teacher education division
for a local college. I've created the database in Access 2000, but I have
created forms for the database in VB 6.0. Now, I'm thinking whether it
will be more efficient to do it this way. I'm helping a friend with her
regular classwork in Access, and one of her current classwork projects is
creating forms in Access to display data.

As I watch her, I'm thinking back to my project and wondering if I should've
done the forms in Access instead. My reason for creating the forms in VB is
to have a good user interface for the faculty and staff who would using the
database. So far, the interfaces will be only for entering, saving and
printing data. But because the total area of each interface, I'm rethinking
my approach.

Right now, I think that my approach is fairly reasonable, considering that
this it my first time attempting a project on the scale that it will be used
on. But, I'm feeling that I'm second guessing myself and feel that I'm doing
it "wrong". I need some advice PLEASE!!!

 

[Joseph Meehan]

It depends on how good you are and what you know best.

 

[Albert D. Kallal]

My reason for creating the forms in VB is
to have a good user interface for the faculty and staff who would using the
database.

So, in exactly what way was the interface different due to using ms-access?
So, why exactly do you get a good interface by using VB? It is very silly to
simply make a statement like "to have a good user interface...", and then
give NO CONCRETE examples as to what you mean?

In fact, the WORST applications I have ever seen are those with a VB front
end to a ms-access databases. Why is this so?

Well, one reason is that VB forms lack consistency. Now of course this lack
of consistency is going to be the fault of the developer. However, ms-access
forms tend to look more similar from form to form. Further, things like the
navigation buttons are always in the same position. Thus, you tend to see a
LOT MORE consistency in terms of the UI for ms-access forms. Since VB does
not force any kind of consistency, then you tend to get really weird and
un-consistent interfaces in VB forms. I seen some Vb appcltions where from
one form to the next, the navigation, and even how you select, or even edit
a record is complete different. You don't see that very often in ms-access.

Of course for the main form, navigation buttons will be RARELY be used in
ms-access also. Only a VERY very poor access developer would consider
opening a form bound to a large table WITHOUT a where clause. Since that
where clause will restrict the record in the form to "one" record, then the
navigation bar will be disabled by any sane developer.

So far, the interfaces will be only for entering, saving and
printing data. But because the total area of each interface, I'm rethinking
my approach.

The data entry problem is rarely the issue. The real issue is searching, and
how you find that record to edit? Here is some thoughts on how searching
should be done. While the following screen shots is ms-access, it applies to
any development platform.

http://www.attcanada.net/~kallal.msn/Search/index.html

Some people think that searching of names is to be allowed in the form via
ctrl-f, or even worse is some think you can use a combo box. Well, gee, we
really do need a society to prevent cruelty to our users!

Note how the above does make much use of continues forms. Since you don't
have continues forms, then you must revert to using some data grid control
(a LOT MORE work!). Continuous forms is only of many spectacular UI things
that we have in access that you don't have in VB. The same goes for
multi-column list boxes. If you look at the following screen, on the left
side is listbox, and on the right side is continues form. Again, both of
these features don't exist in VB. (so, you have to plug in some grids, and
start writing fingers off with tons of code...yuk!). Further, even the large
combo box to select how the search is going to occur (at the top of the
screen) is multi-column (again, lacking in VB), and further, that combo box
is filled automatically in ms-access, ad NO code is needed.

Here is the shot:
http://www.attcanada.net/~kallal.msn/test/gs1.gif

Right now, I think that my approach is fairly reasonable, considering that
this it my first time attempting a project on the scale that it will be used
on.

I am not sure what you mean by reasonable. If you mean that you want to
spend 3 x times the development cost using VB in place of ms-access for no
apparent reason, then perhaps that is reasonable. Most data centric applies
in ms-access CONSERVATIVELY can be completed in 1/3 the time that it takes
in VB (many developers even state that the ratio is even higher). So, your 3
months of work will become 9 months in VB. If you are looking for more work,
then don't use ms-access!

Since one is so much more productive in ms-access, we actually wind up with
a better UI because we can spend more of the software budget in that area.
For example, take a look at the following screen shots for my report
screens. If you look close, you will see that I use the native listbox, and
combo box for ms-access. These un-bound forms then launch reports (using the
fabulous sql "where" clause that they have). The end result is a far better
UI, and MUCH MUCH LESS code then the equivalent VB solution. It is this less
coding time that allows you to add more features like these report screens
to your appcltions.

Here is those report screen shots:
http://www.attcanada.net/~kallal.msn/ridesrpt/ridesrpt.html


You also need to further explain why you think VB is better for the UI. You
don't have the concept of sub-forms in VB (a huge loss). The problem is that
forms in VB are very simple. The learning curve to master ms-access forms is
FAR MORE difficult then the simple VB forms. In ms-access, you have least
double the number of events (thins like before update, after update , on
insert, on current...this list is huge). If you don't take the extra time to
learn how ms-access forms work, then you DO NOT get the increased production
over VB that I was talking about.

Even simple things like cancelling a form load in access is complete
different then VB. In ms-access we have both on-open event, and also a
on-load event. These two events have very distinct and different uses in
access. The on-open has a cancel event which means the form loading CAN BE
CANDLED (coding this in VB is real pain). Once the form loads, then we can
use the on-load event for code/variable initialize etc. Having two nice
events in place of the VB one event is a typical example the zillions of
places in access where we save lots of coding. I could write on for hundreds
of pages about features that save time. If ms-access could NOT save time,
then why ever use the product?

Here is a good article of mine on sub-forms, something I dearly miss in VB.

http://www.attcanada.net/~kallal.msn/Articles/fog0000000005.html

Futher, the coding language in access is VB6 anyway. As always, what tool
you use is going to depend on what you are tying to accomplish. However, for
simple data entry type forms and searching/editing of data, I can't imagine
why one would use VB6?

VB6 has some advantages in some areas, make no mistake about it.

Not knowing more about your applications, I can really say for sure that it
is better to use ms-access. However, for general data entry type appcltions,
there is little reasons to use VB. ms-access is FOR data centric
applications. Data centric products like FoxPro, or ms-access would NEVER
exist if VB was just a good for the task. Why were database products EVER
INVENTED if this was not the case?

As for making something user friendly? Well, that is entirely up to the
developer, and has little to do with using access, or VB. You can easily
make a mess in both of them! You can make a very good UI in both of them
also!

 

[A Future Computer Scientist]

Ok. I see what you are saying, but I think on some issues, you are being a
little harsh. A little about myself. I'm not a professor programmer. I'm
still a novice. All of my programming experience has all be educational.
This is my first time doing a non-educational program. The project of doing
the database came about because of the new job I'm going to be working. I
will be working as tech support for the teache education division of a local
college. The director told me how she wanted to have a database created to
track students who go through the program and post graduation employment
during my job interviews. So, after the last interview, from what we talked
about, I started thinking in my mind on how to design it. So, a little over
a month ago, I started creating the database in Access. Then about a day
after i started the database, I started creating the interfaces. I am doing
this of my own free time and seeing as that the division really needs a
database to keep records, whether I did it or not, I wanted to do.

---------------------------------------------------------

So, in exactly what way was the interface different due to using ms-access?
So, why exactly do you get a good interface by using VB? It is very silly to
simply make a statement like "to have a good user interface...", and then
give NO CONCRETE examples as to what you mean?

In fact, the WORST applications I have ever seen are those with a VB front
end to a ms-access databases. Why is this so?

Well, one reason is that VB forms lack consistency. Now of course this lack
of consistency is going to be the fault of the developer. However, ms-access
forms tend to look more similar from form to form. Further, things like the
navigation buttons are always in the same position. Thus, you tend to see a
LOT MORE consistency in terms of the UI for ms-access forms. Since VB does
not force any kind of consistency, then you tend to get really weird and
un-consistent interfaces in VB forms. I seen some Vb appcltions where from
one form to the next, the navigation, and even how you select, or even edit
a record is complete different. You don't see that very often in ms-access.

Of course for the main form, navigation buttons will be RARELY be used in
ms-access also. Only a VERY very poor access developer would consider
opening a form bound to a large table WITHOUT a where clause. Since that
where clause will restrict the record in the form to "one" record, then the
navigation bar will be disabled by any sane developer.

Maybe I rephrased what I said wrong. I want the interfaces to be user
friendly, because the faculty and staff in the department are NOT very
computer literate and they have no in-house (in the division) IT/IS people,
expect for the MIS department for the college. Bear in mine that the college
is very small. So, I would be the only IT person in the education division
and the only IT person in that particular building. So, the education
faculty/staff may not be the only people to have/need access to the
database.

Each VB form, with the exception of the first form are very consistant. The
only thing that isn't consistant is the buttons, and that's only because the
label names for the buttons.

I think the reason why I think the forms would be "better" in Access is
because of the form design itself. But like I said, I feel that i'm "second
guessing" myself with this. I've even had thoughts of messing around with it
in Java. Actually, I like interfaces done in Java better. To me, Java
interfaces look more "cleaner and leaner".
---------------------------------------------------------

The data entry problem is rarely the issue. The real issue is searching, and
how you find that record to edit? Here is some thoughts on how searching
should be done. While the following screen shots is ms-access, it applies to
any development platform.

http://www.attcanada.net/~kallal.msn/Search/index.html

The reason I'm thinking about my approach is because of printing out the
records. The way I have it printing is one
record, not all of the data in a single table. So that's part of my dilemna.
Because I don't want the buttons in each form to show along with the data.
----------------------------------------------------------

Some people think that searching of names is to be allowed in the form via
ctrl-f, or even worse is some think you can use a combo box. Well, gee, we
really do need a society to prevent cruelty to our users!

Note how the above does make much use of continues forms. Since you don't
have continues forms, then you must revert to using some data grid control
(a LOT MORE work!). Continuous forms is only of many spectacular UI things
that we have in access that you don't have in VB. The same goes for
multi-column list boxes. If you look at the following screen, on the left
side is listbox, and on the right side is continues form. Again, both of
these features don't exist in VB. (so, you have to plug in some grids, and
start writing fingers off with tons of code...yuk!). Further, even the large
combo box to select how the search is going to occur (at the top of the
screen) is multi-column (again, lacking in VB), and further, that combo box
is filled automatically in ms-access, ad NO code is needed.

Here is the shot:
http://www.attcanada.net/~kallal.msn/test/gs1.gif

The link above didn't work. The other one above it did. I have the data
controls on the forms to go through each record.
---------------------------------------------------------

I am not sure what you mean by reasonable. If you mean that you want to
spend 3 x times the development cost using VB in place of ms-access for no
apparent reason, then perhaps that is reasonable. Most data centric applies
in ms-access CONSERVATIVELY can be completed in 1/3 the time that it takes
in VB (many developers even state that the ratio is even higher). So, your 3
months of work will become 9 months in VB. If you are looking for more work,
then don't use ms-access!

I use "reasonable" because like I said earlier, this is my first time doing
any type of project of this type on any scale; large or small. Also I use
reasonable is because I seem to be a "natural" at programming. I don't use
Access on a daily basis, but I do use it. I do programming almost everyday.
So, that was the reason I believed I could create a decent database. I'm
going soley from the VB point of view, not VBA. And since I didn't have to
time to read up on VBA, I did(do) what I know. I'm probably one of those
rare programmers who don't see "time" with development. What maybe a lot of
work to you won't seem like that to me. I'm not saying that I write programs
very fast intentionally, it just turns out that way, and the coding is very
good. I'm not saying this is the norm, because it's not and i'm not saying
that I'm a very good programmer, becasue I know I'm not. Because of the
amount of data going to be entered, it's amazing that I have gotten the
interfaces and database created as far as it has.

Since one is so much more productive in ms-access, we actually wind up with
a better UI because we can spend more of the software budget in that area.
For example, take a look at the following screen shots for my report
screens. If you look close, you will see that I use the native listbox, and
combo box for ms-access. These un-bound forms then launch reports (using the
fabulous sql "where" clause that they have). The end result is a far better
UI, and MUCH MUCH LESS code then the equivalent VB solution. It is this less
coding time that allows you to add more features like these report screens
to your appcltions.

Here is those report screen shots:
http://www.attcanada.net/~kallal.msn/ridesrpt/ridesrpt.html

This link didn't work either. I can't set it up for SQL, because like I said
before, the factuly/staff aren't computer-literate. Even explaining the
"simplest" of functions of the database confused the director. That's why it
really has to be as user-friendly as possible. So alot of things that would
normally left out or doesn't need to be in, it would have to be because of
the computer illiteracy.

----------------------------------------------------------

You also need to further explain why you think VB is better for the UI. You
don't have the concept of sub-forms in VB (a huge loss). The problem is that
forms in VB are very simple. The learning curve to master ms-access forms is
FAR MORE difficult then the simple VB forms. In ms-access, you have least
double the number of events (thins like before update, after update , on
insert, on current...this list is huge). If you don't take the extra time to
learn how ms-access forms work, then you DO NOT get the increased production
over VB that I was talking about.

Like I was saying, I'm probably second guessing myself. It may not even be a
matter of VB forms being better than Access forms. After I saw my friend
working on her's, I just started thinking.

Sub forms; would you explain that to me, because I've never encountered
that. Would it be under another name or phrase? Forms in general, I have a
grasp of the concept.

---------------------------------------------------------

even simple things like cancelling a form load in access is complete

different then VB. In ms-access we have both on-open event, and also a
on-load event. These two events have very distinct and different uses in
access. The on-open has a cancel event which means the form loading CAN BE
CANDLED (coding this in VB is real pain). Once the form loads, then we can
use the on-load event for code/variable initialize etc. Having two nice
events in place of the VB one event is a typical example the zillions of
places in access where we save lots of coding. I could write on for hundreds
of pages about features that save time. If ms-access could NOT save time,
then why ever use the product?

Here is a good article of mine on sub-forms, something I dearly miss in VB.

http://www.attcanada.net/~kallal.msn/Articles/fog0000000005.html

Futher, the coding language in access is VB6 anyway. As always, what tool
you use is going to depend on what you are tying to accomplish. However, for
simple data entry type forms and searching/editing of data, I can't imagine
why one would use VB6?

If I'm not mistaken, isn't the coding in VB and VBA (Visual Basic for
Applications) totally different. I have read some on VBA and the coding for
even the most basic events is totally different from VB. That's why I
decided not to create the interfaces in Access exclusively.

-----------------------------------------------------

VB6 has some advantages in some areas, make no mistake about it.

Not knowing more about your applications, I can really say for sure that it
is better to use ms-access. However, for general data entry type appcltions,
there is little reasons to use VB. ms-access is FOR data centric
applications. Data centric products like FoxPro, or ms-access would NEVER
exist if VB was just a good for the task. Why were database products EVER
INVENTED if this was not the case?

The main reason for creating the interfaces in VB because the application is
wholly data centric; there's nothing general about the data that will be
entered in. The only applications that the faculty/staff use is Microsoft
Word and possibly Excel, but that's it. They had been using Word and Excel
97 and just recently upgraded to Office XP.

--------------------------------------------------------

 

[cor_blimey]

I agree with you 'A Future Computer Scientist'.

Visual Basic provides a better way of creating a much nicer gui front end to
a database.

As for accusations of 3x development costs, mixing and matching of forms,
forms having no consistency, well THAT is bad programming. Visual Basic is
what is known as a RAD. A Rapid Application Development. This means by
definition that it is a FAST method of creating simple user interfaces.

Why do forms have to look different? Programmers use different methods to
create consistency.

In VB there are menu's, classes, MDI forms and children, Modules - All of
these help a programmer create a common look and feel to an application.
It also has full Visual Basic capabilities - whereas Access has only VBA to
rely on?

In my opinion Access isn't really a database. It was a bolt on to Microsoft
office that they thought would be nice. Therefore a 'CHEAP' alternative to a
real database.

A sort of easy access database for the home user!!!!!!

I have been programming for 7 years from Cobol, T-SQL, PRO-IV, Visual Basic,
PL/SQL, ORACLE Developer, ORACLE DATABASE, MS ACCESS, SQL Server 6.5 and
7.0, ASP, JAVA, HTML, JSCRIPT.

I have also used Access in a commercial environment and let me tell you that
it sucks big time. The amount of time you spend restoring the bloody thing
is unbelievable.

Out of all the languages I have used, the one I have found to be the best as
far as GUI development is Visual Basic bar none.

Also, you develop the forms in Access - how do you then port those forms
across when you change database?

In VB it is simply a matter of adjusting your ADO or DAO (yuck) connections.
In Access you will have to start from scratch with a new development?

If you aren't going to change the database what about source control? How
are you going to find your different versions of source?

VB integrates into Sourcesafe perfectly (and I have used a few source
control applications and still find Microsoft Sourcesafe the most user
friendly - and before you ask which ones I have used PVCS and StarTeam
amongst others), and helps control the development.

You can listen to who you want but my money is going to using VB.

It is a true development suite (unlike access which uses parts of VB), it
can be used to create nicer GUI's, more stable (if coded properly), and
gives greater scope for expansion.

By expansion I mean, what if this little project turned into a numb er of
little projects. The same application can be used by using an MDI form and
child forms. Thereby allowing you to use more than one database within the
same application (or suite of forms) whereas Access will not allow you to do
this as the forms will be attached to the same database.

Sure you could port or link the data from another database to your database
but what the hey - thats not easy to manage. Better to keep your databases
seperate and manageable.

James

 

[Robert Berman]

I agree with you 'A Future Computer Scientist'.

Visual Basic provides a better way of creating a much nicer
gui front end to a database.

As for accusations of 3x development costs, mixing and
matching of forms, forms having no consistency, well THAT
is bad programming. Visual Basic is what is known as a RAD.
A Rapid Application Development. This means by definition
that it is a FAST method of creating simple user
interfaces.

Why do forms have to look different? Programmers use
different methods to create consistency.

In VB there are menu's, classes, MDI forms and children,
Modules - All of these help a programmer create a common
look and feel to an application. It also has full Visual
Basic capabilities - whereas Access has only VBA to rely
on?

In my opinion Access isn't really a database. It was a bolt
on to Microsoft office that they thought would be nice.
Therefore a 'CHEAP' alternative to a real database.

A sort of easy access database for the home user!!!!!!

I have been programming for 7 years from Cobol, T-SQL,
PRO-IV, Visual Basic, PL/SQL, ORACLE Developer, ORACLE
DATABASE, MS ACCESS, SQL Server 6.5 and 7.0, ASP, JAVA,
HTML, JSCRIPT.

I have also used Access in a commercial environment and let
me tell you that it sucks big time. The amount of time you
spend restoring the bloody thing is unbelievable.

Out of all the languages I have used, the one I have found
to be the best as far as GUI development is Visual Basic
bar none.

Also, you develop the forms in Access - how do you then
port those forms across when you change database?

In VB it is simply a matter of adjusting your ADO or DAO
(yuck) connections. In Access you will have to start from
scratch with a new development?

If you aren't going to change the database what about
source control? How are you going to find your different
versions of source?

VB integrates into Sourcesafe perfectly (and I have used a
few source control applications and still find Microsoft
Sourcesafe the most user friendly - and before you ask
which ones I have used PVCS and StarTeam amongst others),
and helps control the development.

You can listen to who you want but my money is going to
using VB.

It is a true development suite (unlike access which uses
parts of VB), it can be used to create nicer GUI's, more
stable (if coded properly), and gives greater scope for
expansion.

By expansion I mean, what if this little project turned
into a numb er of little projects. The same application can
be used by using an MDI form and child forms. Thereby
allowing you to use more than one database within the same
application (or suite of forms) whereas Access will not
allow you to do this as the forms will be attached to the
same database.

Sure you could port or link the data from another database
to your database but what the hey - thats not easy to
manage. Better to keep your databases seperate and
manageable.

James

There was, a few years back on one of the ACCESS newsgroups,
an oft vitriolic very informative thread debating the merits
of ACCESS vs. Visual Basic. If you worked your way past the
vitriol you learned a great deal about both. I cannot relegate
ACCESS to simply an Office add-on. In truth it made me a
rather nice living for more years than Visual Basic has done.
I suspect that if DAO had maintained its title as the "Only
and the best way", then I would still be developing entirely
in ACCESS using VBA as necessary to link to whatever I needed.
It all really does work very nicely.

In my opinion, ACCESS forms run rings around Visual Basic
forms; not at all in creativity or flexibility but in
consistency. I think this is what Albert was stressing and
this is the real dichotomy between the two environments.
Never, in my opinion, has there been a language as flexible
and as powerful as Visual Basic. VB is to the PC as PL1 was to
the main frame. Never have I seen a language as powerfully
consistent in its ability to produce a good product as ACCESS.
If you learn a few very basic ground rules in ACCESS you can
consistently turn out really good applications. You can, with
a bit more work, be reasonably creative within those
guidelines. And, I think, because of this, you might want to
strongly consider using ACCESS. You seem to be a rather
staunch member of the academic community and your interest in
programming may be as something to further enhance your
standing in that community. You will spend far less time
trapped in a learning curve using ACCESS.

From the other point of view....consider using VB if your bent
is more creative, even artistic. You may find each form
dictates its own functionality. That what is consistent does
not well integrate into what your form represents. If you wish
to explore the incredible flexibility available to your
project, then, by all means, jump into Visual Basic because
now you are not confined to a specific form design, and you
are even open to a multitude of databases to pick and choose
amongst.

So, perhaps you should first decide on what you want to get
out of this project for yourself.

Good Luck.

 

[A Future Computer Scientist]

I agree with you 'A Future Computer Scientist'.

Visual Basic provides a better way of creating a much nicer gui front end to
a database.

As for accusations of 3x development costs, mixing and matching of forms,
forms having no consistency, well THAT is bad programming. Visual Basic is
what is known as a RAD. A Rapid Application Development. This means by
definition that it is a FAST method of creating simple user interfaces.

Why do forms have to look different? Programmers use different methods to
create consistency.

In VB there are menu's, classes, MDI forms and children, Modules - All of
these help a programmer create a common look and feel to an application.
It also has full Visual Basic capabilities - whereas Access has only VBA to
rely on?

In my opinion Access isn't really a database. It was a bolt on to Microsoft
office that they thought would be nice. Therefore a 'CHEAP' alternative to a
real database.

A sort of easy access database for the home user!!!!!!

I have been programming for 7 years from Cobol, T-SQL, PRO-IV, Visual Basic,
PL/SQL, ORACLE Developer, ORACLE DATABASE, MS ACCESS, SQL Server 6.5 and
7.0, ASP, JAVA, HTML, JSCRIPT.

I forgot about Cobol as a database creator.

 

[A Future Computer Scientist]

There was, a few years back on one of the ACCESS newsgroups,
an oft vitriolic very informative thread debating the merits
of ACCESS vs. Visual Basic. If you worked your way past the
vitriol you learned a great deal about both. I cannot relegate
ACCESS to simply an Office add-on. In truth it made me a
rather nice living for more years than Visual Basic has done.
I suspect that if DAO had maintained its title as the "Only
and the best way", then I would still be developing entirely
in ACCESS using VBA as necessary to link to whatever I needed.
It all really does work very nicely.

In my opinion, ACCESS forms run rings around Visual Basic
forms; not at all in creativity or flexibility but in
consistency. I think this is what Albert was stressing and
this is the real dichotomy between the two environments.
Never, in my opinion, has there been a language as flexible
and as powerful as Visual Basic. VB is to the PC as PL1 was to
the main frame. Never have I seen a language as powerfully
consistent in its ability to produce a good product as ACCESS.
If you learn a few very basic ground rules in ACCESS you can
consistently turn out really good applications. You can, with
a bit more work, be reasonably creative within those
guidelines. And, I think, because of this, you might want to
strongly consider using ACCESS. You seem to be a rather
staunch member of the academic community and your interest in
programming may be as something to further enhance your
standing in that community. You will spend far less time
trapped in a learning curve using ACCESS.

That's probably why I'm having the second guessing because of the
consistancy of the forms in Access. But you are right, the learning curve
(Or the relearning curve) for Access wouldn't be existant for me. This is
really advanced for me, because in my beginning learning of Access, we were
never taught even remotely how to do the project I'm doing. I'm picking it
up all on my own. So it's very surprising that it is going as well as it is
and with no real big problems.

From the other point of view....consider using VB if your bent
is more creative, even artistic. You may find each form
dictates its own functionality. That what is consistent does
not well integrate into what your form represents. If you wish
to explore the incredible flexibility available to your
project, then, by all means, jump into Visual Basic because
now you are not confined to a specific form design, and you
are even open to a multitude of databases to pick and choose
amongst.

I tend to be more creative then artistic, even as a programmer. I want the
forms to be as consistant as I can get them. Because of the type of data
that will be in the database, there is alot of redundacy to the database, so
the forms have no choice but to be consistant. I've entered some test data
in to test the forms and so far the functionality is good. To me even better
than I expected, and that's because since this project is the first I've
ever done on the scale, I've surprised myself. But don't get me wrong, I'm
open to everything. It's only because VB and Access are "fresh" in my mind,
I jump on them.

 

[Larry Linson]

Dear Future Computer Scientist:

You'd have had a lot more readers following this thread if you had been
selective in your quoting. I had to scroll through pages and pages before
finally finding the paragraph you had added to the preceding post. And, it'd
probably also be appreciated if you wouldn't crosspost to quite so many
newsgroups.

Anyone who, like an earlier poster in this thread, tells you that it is a
bunch of malarkey that it will take an experienced developer three times as
long to develop the same database application in VB as in Access has just
not used both, at least not sufficiently to be proficient. Two-to-five times
as long to develop the indetical application in classic VB is a consensus in
the newsgroups from people who are proficient in both VB and Access.

Access is far more database-development-efficient, for one reason, because
of its significantly richer data event model. For a presentation on choosing
Access or VB as a front-end to databases that I did for my user group, and
that was well-received by both the VB and Access SIG members, visit
http://appdevissues.tripod.com/downloads.htm.

And, for the record, I have been a user of classic VB since version 1 --
that would be either 1991 or 1992, and of Access since its version 1 --
which I didn't get until January 1993, after it had been on the shelves for
a whole month.

Larry Linson
Microsoft Access MVP

 

[Steve Gerrard]

I tend to be more creative then artistic, even as a programmer. I want the
forms to be as consistant as I can get them. Because of the type of data
that will be in the database, there is alot of redundacy to the database, so
the forms have no choice but to be consistant. I've entered some test data
in to test the forms and so far the functionality is good. To me even better
than I expected, and that's because since this project is the first I've
ever done on the scale, I've surprised myself. But don't get me wrong, I'm
open to everything. It's only because VB and Access are "fresh" in my mind,
I jump on them.

Here's two more cents worth.
The datasheet view in Access, with some of the standard toolbar buttons
available, can be very sweet for users. They can highlight the middle three
letters of someone's name, click the lightening bolt, and have a list "filtered
by selection" in a jiffy. They can rearrange the column order, sort, hide
columns, etc.
Off the shelve, the VB datagrid won't do that. You can try to code it all
yourself, or buy a nice a grid control. If you do, though, you can now use ADO,
connect to SQL server, do color coding of grid squares, and so on.
Just an example. Both tools are useful, and fortunately, we don't have to pick
one and throw the other away. It all depends on how many users, how extensive is
the project, what features are worth extra effort, what kind of non-database
programming is needed, and so on.
I have seen abysmal Access databases, excellent VB applications, elegant Access
databases, and appalling VB applications. Consistency and intelligent design is
up to the designer/programmer, regardless of what tools they use.

 

[hal boyles]

Easy there Einstein! He said he was a novice....Access may be the best tool
for him. I don't have all your credentials crawling out of my backside but
Access is a viable tool for MANY business applications. VB has the power
and will be the boss tool for a long time, but, Access will be around for
quite a while as well.

Why not criticize him for not considering Oracle for his smallish
application. The devlopment time and cost are obviously of no consequence
to you....

Narrow minds, egocentric ideologies, morons....smart people can belong to
any of those groups.

Relax.

 

[cor_blimey]

Easy there Einstein! He said he was a novice....Access may be the best tool
for him. I don't have all your credentials crawling out of my backside but
Access is a viable tool for MANY business applications. VB has the power
and will be the boss tool for a long time, but, Access will be around for
quite a while as well.

Why not criticize him for not considering Oracle for his smallish
application. The devlopment time and cost are obviously of no consequence
to you....

Narrow minds, egocentric ideologies, morons....smart people can belong to
any of those groups.

Relax.

Just giving my point of view on whether I would use VB or Access and why.

I was not criticizing him - read the post again hero

And if you feel the need to come around protecting the beginners by slagging
off others who are offering advise - then please don't.

I am neither narrow minded, egocentric nor a moron. You dont know me, you
will never know me, so try not to categorise someone you dont know.

Try answering the question as it was put instead of trying to put me down in
one of your posts.

And I was relaxed until you decided to join the debate and start flaming.

 

[Albert D. Kallal]

Maybe I rephrased what I said wrong. I want the interfaces to be user
friendly, because the faculty and staff in the department are NOT very
computer literate and they have no in-house (in the division) IT/IS people,
expect for the MIS department for the college. Bear in mine that the college
is very small. So, I would be the only IT person in the education division
and the only IT person in that particular building. So, the education
faculty/staff may not be the only people to have/need access to the
database.

After spending any amount of time developing ms-access applications, the
users
will NOT see any of the ms-access interface anyway. Stuff like custom menus
etc. should be the norm. I not sure what you mean by the above? Any good
application written in ms-access does NOT have to revel this fact to the end
users (they will never have to know, or even see the ms-access interface).

The reason I'm thinking about my approach is because of printing out the
records. The way I have it printing is one
record,

Hum, not sure exactly what you mean by the above, but in ms-access
you can print one record with 2 lines of code! (try that in VB!).

The code behind a button on your form to print one
record is:

me.Refersh 'force disk write so report see changes
docmd.openReport "TheReport",,,"id = " & me.ID

That is it...two lines of code!

If you want to send the record to a word merge template doc, then grab my
sample code at:

http://www.attcanada.net/~kallal.msn/msaccess/msaccess.html

This link didn't work either.

Gee, I don't know why you are having trouble with those links...

Try it again:

http://www.attcanada.net/~kallal.msn/ridesrpt/ridesrpt.html

I can't set it up for SQL, because like I said
before, the factuly/staff aren't computer-literate.

I don't understand the above? You users will NEVER see the tons and tons of
sql that you use..so not sure why this is a issue?

Sub forms; would you explain that to me, because I've never encountered
that. Would it be under another name or phrase? Forms in general, I have a
grasp of the concept.

Here is some notes on sub-forms:

http://www.attcanada.net/~kallal.msn/Articles/fog0000000005.html

If I'm not mistaken, isn't the coding in VB and VBA (Visual Basic for
Applications) totally different.

No, the syntax for the language is virtually the same. The difference is the
objects you work with!. Since the form object in ms-access is completely
different the VB forms object, then for sure things like form events are
different...but the language syntax is the same.

I have read some on VBA and the coding for
even the most basic events is totally different from VB. That's why I
decided not to create the interfaces in Access exclusively.

That is correct, the event model for ms-access is FAR MORE complex. However,
once learned, that is why 1 month of work is ms-access = 3 months of work in
VB. So, when I say the langue is the same, it is, but the objects your work
with are certainly different.

For sure, learning the syntax of VB is not hard, but as you note, the
objects.

 

[Albert D. Kallal]

That is a conservative rating by most development houses


,> mixing and
I absolute agree. But don't mix in the issue of 3 x the productivity with
that of the poor practice of the developers, and inconsistent forms. In the
issue of inconsistent forms, yes, that is bad developers. On the issue of 3x
the productivity...that is just your lack of knowledge in this area.

There is most certainly an issue of "scaling" the development process, and
after a certain point, the VB environment will certanly start to be come a
better choice, but then we would be talking about a multi-team and person
development project.

Visual Basic is what is known as a RAD.

That is correct. However, it is not a database RAD product like ms-access!
VB falls major short as compared to ms-access in this area. VB is NOT a data
centric product, and there fore takes MUCH MORE work to build data centric
appcltions.

Gosh, you really are in the dark on this one. The VB, and VBA langue are
really at par for all intensive purposes. Virtually all of the features such
as creating class objects has been ms-access since a97. (they even share the
same code library now!). The ONLY thing now difference is a few threading
options, native vs p-code, and creating of com objects. The rest of the
tools are the same, and even share the same compiler and dlls library.

I create and use class objects with the ms-access IDE all the time:
You can read the following:

http://www.attcanada.net/~kallal.msn/Articles/WhyClass.html


Of course ms-access is not database! It is VB6 database CLIENT development
environment. You don't seem understand that you don't have to use JET with
ms-access. (this is common miss-conception).

Ah, I see, the problem here is you can't tell the difference between
ms-access and the database engine! You are taking about the JET database
engine, and not ms-access! (gosh, please in the future try and get your
terms straight. You are causing such incredible confusing here). Somehow
along the way you either have not kept up with ms-access, or you don't
understand he difference between ms-access and JET. Ms-access is actually
the most popular client development tool to oracles own database next to
their own tools!

Since office 2000, the office CD has shipped with 2 database engines, JET,
and the MSDE engine (MSDE is a 100% compatible with sql-server. We are
taking about a native OLEdb connection to sql server WITHOUT the need for
JET (there is not even local tables when you do this with ms-access).

Who ever assumed or said that you must use JET with ms-access? You don't
have to, and clearly you don't seem to understand this. Or perhaps you can't
understand the difference between a database and a client like ms-access?

Gosh, you have so much reading to do here. Check out:

http://www.granite.ab.ca/access/splitapp.htm

http://www.microsoft.com/accessdev/articles/bapp97/chapters/ba15_3.htm

Again, you have not a clue here.

The visual studio source control has worked with ms-access for years. Again,
you know so little of what you speak. I not looking for a argument here, but
you are just making all kinds of statements about something that you know so
little of! It is just such a disservice to the readers when you do this. It
hurts to see such wrong information being posted, and for me to correct it
really put you and me in a situation that is not comfortable at all. I not
looking to fight, but at least lets try and get some of this stuff straight.

Any ms-access developer with a brain would do the above. It is even standard
fair to do this when using a JET file share. Why do you assume that
ms-access developers are so stupid, and would not do the above? I hope you
problem is that you just have failed to keep up with the ms-access product
is all about.

Here is some fast facts on the office developer edition:

http://www.microsoft.com/office/developer/suite/fastfacts.asp