access vs visual basic 6.0 vs visual basic.net

  • Thread starter Thread starter Brian
  • Start date Start date
The article at the URL you previously posted was enough to convince me that
I have no interest in what Joe Celko has to say on this particular subject.
Tell me why you think I'm wrong, rather than why Joe Celko thinks I'm wrong,
and we might have something to talk about. Otherwise, we're done here.
--
Brendan Reynolds (MVP)
http://brenreyn.blogspot.com

The spammers and script-kiddies have succeeded in making it impossible for
me to use a real e-mail address in public newsgroups. E-mail replies to
this post will be deleted without being read. Any e-mail claiming to be
from brenreyn at indigo dot ie that is not digitally signed by me with a
GlobalSign digital certificate is a forgery and should be deleted without
being read. Follow-up questions should in general be posted to the
newsgroup, but if you have a good reason to send me e-mail, you'll find
a useable e-mail address at the URL above.
 
...
The article at the URL you previously posted was enough to convince me that
I have no interest in what Joe Celko has to say on this particular subject.
Tell me why you think I'm wrong, rather than why Joe Celko thinks I'm wrong,
and we might have something to talk about. Otherwise, we're done here.

I have no first hand experience of any disasters resulting from use of
proprietary SQL. A renowned SQL-92 exponent does but you're not
interested. Sure, we're done.

--
 
I am a developer that has worked closely with both Access and VB since
windows 3.1. I also teach programming at a local college. One of
things I don't think you are mentioning in your arguments is that a
developer should pick their tools based on need. Both tools have good
and bad points. The question is what does the project need. A good
developer gets the development language that fits the project's needs,
they don't make the project fit into their programming language. An
example would be when Access fits you interface needs but not your
reporting needs so you select Crystal Reports because you have the
scheduler for it so you can run reports during off hours so they are
printed when you walk in the next morning. My main point is keep your
options open and be willing to switch as needed. The flexibility makes
you more valuable and more employable!

As for learning a language I would pick VB over Access. Access is a
little more structured the VB and learning with that structure makes
it a lot harder to make the transition. Learning with a language that
is more open forces the developer to learn to create their structure
at design. Personally, I prefer teaching in C first. Also, if you
learn with out the structure you know to appreciate it more when you
have it :-)
 
at design. Personally, I prefer teaching in C first. Also, if you

This is a common failing in teachers: the desire to teach
ideas in the order in which they make sense AFTER you have
subject coverage, rather than in the order in which they
make sense BEFORE you have subject coverage......

my 2c
sorry
(david)
 
(e-mail address removed) wrote ...
A good
developer gets the development language that fits the project's needs,
they don't make the project fit into their programming language.

This discussion is about the MS Access forms engine, not language per
se.
As for learning a language I would pick VB over Access.

The language is VBA and is common to both.
example would be when Access fits you interface needs but not your
reporting needs so you select Crystal Reports

My example, my whole point, is often Jet fits my lightweight database
needs but I don't think the MS Access interface fits my needs. Adding
MS Access development as well as VB to my resume could only be a good
thing, but like you if I had a choice between the two, I'd choose VB.
(Actually, I do have MS Access on my resume because in my experience
when someone says 'Access' they usually mean Jet).

--
 
OK, how did you get that from my statement? Where in my statement did
I state, "Oh, by the way, I'm not going to explain to you why we are
working in this language and not the one you want to learn in!" Many
of my students had worked with other languages before they got to my
class and I would explain to them why you need to learn the ability
not to count on the tools to cover you and give you structure. Heck,
it was the main theme of the class.

Of course I still had students that would complain and make statements
like, "You don't have to do that in VB". Most of them just didn't want
to work hard enough to do good job.
 
(e-mail address removed) wrote ...
Many
of my students had worked with other languages before they got to my
class and I would explain to them why you need to learn the ability
not to count on the tools to cover you and give you structure.

Sounds like a good idea to me. MS Access users should try to use Jet
without using the MS Access UI, would help them see the 'wood from the
trees'. More common than not in these ngs, MS Access gets mistaken
for Jet.

--
 
The language is VBA and is common to both.

Yes, this is true but the shell in which you work is not. You have to
look at it in it's total package. In Access you can call the built in
tool bar commands and have tools like CurrentDB(). I have helped
people who have only ever work in Access convert to VB and they had a
ton of trouble making the switch because of not having those Access
specific tools.
 
[takes a good part of a year to 'un-learn'] I just don't agree
with that. Not even close. <<

Okay, how many hundred programmers do you have from your training
classes and books to base a disagreement with my experience? I find
it begins with the terminology -- Rows are not records; fields are not
columns; tables are not files; there is no sequential access or
ordering in an RDBMS, so "first", "next" and "last" are totally
meaningless. But look at the newsgroups and see how many programmers
have no clue about even this most basic conceptual level.
useful business tools with Access, so you might find an Access
'developer' who has no programming skills AT ALL and takes a good part
of year to pick up ANY programming skills. <<

I get those guys too :) More often than not, they start with simple
things that are useful, so then they are asked to port it to a real
database or do something complex. They fail horribly and I get a
call. I bill "three digits" per hour to fix it.

Also, for the record, I msaw the first public announcemnt of ACCESS at
a Comdex as trade press (it sorted dates alphabetically and it crashed
while Bill Gates did the demo) and I was on retainer to the ACCESS
group at MS to help them get it into ANSI specs.
 
--CELKO-- said:
[takes a good part of a year to 'un-learn'] I just don't agree
with that. Not even close. <<

Okay, how many hundred programmers do you have from your training
classes and books to base a disagreement with my experience? I find
it begins with the terminology -- Rows are not records; fields are not
columns; tables are not files; there is no sequential access or
ordering in an RDBMS, so "first", "next" and "last" are totally
meaningless. But look at the newsgroups and see how many programmers
have no clue about even this most basic conceptual level.
You will find that it exactly the same as those who don't "understand" that
a loop is not really a loop but a C++ program which is not really a
C++program but an assembly language program which is really machine
language.
The terms are interchangeable in the world we work in.
Further since one of the conditions is that the storage method is not of
importance in a "real" Relational database, they rows could very well be
records which line up in nice neat columns.
 
Back
Top