VBA

[Greg]

I am considering spending some time and possibly $ in learning VB or VBA.

If you begin the learning process with VBA for Excel. Will it be valuable or
not, if you want to eventually apply VBA to Access.

VBA seems to me to be more understandable in the EXCEL environment than the
Access Environment.

I guess the question is "is the path to learning VBA shorter by learning VBA
for Excel first and then VBA for Access or to directly learn VBA for Access"

OR is VBA so entwined with EXCEL and ACCESS there is no transferability of
knowledge from one to the other.

Thank You,
Greg

 

[MH]

Why not learn them both?

The core language is exactly the same in both applications, it's only the
object models that differ.

MH

 

[NetworkTrade]

VB (or really .Net Visual Studio) is widely taught and classes can by found
at many community colleges....and they are typically quite affordable

I don't think I've ever seen a VBA class taught in my area.

Simplistically, I view VBA essentially to be a subset (or maybe a superset -
not sure)of VB in that it has specific terms/functions/commands unique to the
Office Suite Products.

 

[Todos Menos [MSFT]]

hey NooB

you should focus on SQL Server; VB / VBA is obsolete

and Excel is a waste of time

learn SQL and a nice reporting tool, for example Reporting Services or
Crystal Reports

MDB is for babies and retards

-Todos

 

[Greg]

MH,
Thank You,

I think my age has something to do with my problem. I have written in
assembly languge, sobel,cobol,basic, fortan, and c . All procedural- no OO
or event driven experience. Possibly I am too far behind the curve to make
sense of VBA or VB. What do you think!!

Thanks,
Greg

 

[(PeteCresswell)]

Per Greg:

I think my age has something to do with my problem. I have written in
assembly languge, sobel,cobol,basic, fortan, and c . All procedural- no OO
or event driven experience. Possibly I am too far behind the curve to make
sense of VBA or VB. What do you think!!

Once I got the idea of an event-driven application through my head it seemed to
me tb a *lot* easier than COBOL - mainly because of the ability to step through
the code.

I'd recommend starting with MS Access VBA because with it you can create more of
a "real" application. i.e. One with a home screen/menu, various other screens
to support different functionality - all built on tables in a back end.

You can do all that with Excel, but it seems to me tb pushing the envelope - and
the objects you'd use to construct a screen aren't nearly as friendly.

Also, get some books.

When I was starting, I found a lot of help in Getz, Litwin, and Gilbert's
"Access 2000 Developer's Handbook (two telephone-book-sized volumes).

For general rules/guidelines, I live and die by Steve McConnel's "Code
Complete".

 

[(PeteCresswell)]

Per (PeteCresswell):

Once I got the idea of an event-driven application through my head it seemed to
me tb a *lot* easier than COBOL - mainly because of the ability to step through
the code.

I should qualify that by saying you'll write a *lot* more code to put up an
equivalent app.... because managing the UI becomes a much larger portion of the
total effort. You can't just put up a menu and straightjacket the user into
"N" choices. But it's kinda fun - trying to stay one step ahead of the user.

 

[Tony Toews [MVP]]

I think my age has something to do with my problem. I have written in
assembly languge, sobel,cobol,basic, fortan, and c . All procedural- no OO
or event driven experience. Possibly I am too far behind the curve to make
sense of VBA or VB. What do you think!!

Not at all. I'm a former mini-computer on the IBM S/34, S/36, S/38 and AS/400
mostly with RPG in the '80s. A bit of work during high school on WATFIV, PL/C and
Assembler. Once I got the hang of events all was well. I don't use class modules
like I should as I just don't quite "get them".

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

 

[storrboy]

.... I don't use class modules

like I should as I just don't quite "get them".

I probably use them too much. I find it easier to write and manage
code that way.
For me the hardest part of learning the language was remembering the
object models and functions. The syntax and stuff was kind of straight
forward for me as I had little experience with other languages (some
java and php but not much). A good Access/VB(A) book is a must and
hands on experimenting fills in the rest.

 

[Dirk Goldgar]

In

I'm a former mini-computer

Whereas now you're a maxi-computer?

 

[MH]

You don't have to create classes when you are programming in VBA, that's the
beauty of the language - the functionality is there if you want to use it
but you can just use procedural code if you wish.

You have to understand objects to a certain extent though, all the
applications are built up of objects, this tree like structure of objects is
called the "object model". Excel is fairly straightforward in that it has
one object model, Access is a bit more complicated as it has one object
model for forms, reports etc. and a seperate object model for handling data
(this can be either DAO (Data Access Objects) or ADO (ActiveX Data
Objects)). Which one you use is up to you, I don't tend to argue the case
for either although I do use DAO wherever possible over ADO.

MH

 

[George Nicholson]

Which do you you use more?

In my case, I taught myself VBA using Excel at an old job (converting old
2020 macros from a Wang to a PC). Eventually I changed jobs and added
Access. But, at the time I was using spreadsheets a lot more than
databases, so it seemed logical to start with Excel. Your needs may be
different.

They have different object models, but once you get the basics of one,
finding your way around another isn't too bad. The good news is that program
logic is the same in Excel as it is in Access (i.e., a loop is still a loop,
ditto If..Then..Else structures, etc.).

One tool Excel has that Access doesn't is the macro recorder. When you're
just starting out it can provide some great "how-to" examples on demand
(granted, they usually require a lot of cleaning up to make them presentable
because they are remarkably "dumb" robotic outputs, but "snap" & they're
there). I still use it occasionally to quickly point me toward the correct
method/property to look up in Help or refresh my memory about some
functionality I haven't used in years (the innards of a pivot table). AFAIK,
Excel is the only Office app that does have a macro recorder, which in my
mind may make it the single best place to learn VBA *as long as you use
spreadsheets regularly*.

HTH,

 

[Tony Toews [MVP]]

A a r o n K e m p f wrote:

Note that this person is really A a r o n K e m p f and that he is not an employee
of Microsoft.

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 Toews [MVP]]

A a r o n K e m p f wrote:

Note that this person is really A a r o n K e m p f and that he is not an employee
of Microsoft.

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

 

[Todos Menos [MSFT]]

Tony;

stop smoking crack, jackass-- I never claimed to be a MS employee

and for the record, MDB is for lamers and retards.

Everyone should be using ADP for everything-- it's sortof like MDB but
it's reilable, dependable, secure and consistent

 

[Todos Menos [MSFT]]

correction

if 'easier to write and manage code' means that your code is MORE
VERBOSE AND SLOWER PERFORMING?

then I agree with you.

as it is; it is not easier for anything; and it runs slower

eat shit class wimp

'oh is it the trendy thing to do'

GAG
classes = waste of time and effort

 

[Todos Menos [MSFT]]

Tony;

that is the only thing that we've ever agreed upon.

it is said that 90% of vb6 developers 'never wrote a class'

why in the hell did they make OOP a central facet to vb7 and vb8?

WE DON'T NEED THE FEATURE, WE USE DATABASES INSTEAD OF CLASSES

 

[Todos Menos [MSFT]]

why in the hell would you use DAO over ADO?

ADO is ALWAYS FASTER and it does everythign possible in a single
library-- that you dipshits do in DAO

 

[Todos Menos [MSFT]]

re:
Excel is the only Office app that does have a macro recorder

what about MS Project and Visio?

and what about WORD?

come on dude; start speaking the truth.

SPreadsheets are for friggin losers.
I mean-- do you really NEED to build the same report week in and week
out?

Copy and paste? Are you for real?

Spreadsheet people are retards; they all need to learn Crystal Reports
and SQL Server

 

[Todos Menos [MSFT]]

Dim strSql as string
strSql = "Create Procedure spHappy As Select * from Sysobjects"

CurrentProject.connection.execute strSql

How can you beat that?

Let me guess-- with a dozen lines of DAO code?

ROFL

eat shit DAO newbie