Open source alternative for MsAccess?

On Mon, 14 Jun 2004 20:39:10 GMT, Jan Panteltje <pN*************@yahoo.com>
wrote:

**** Post for FREE via your newsreader at post.usenet.com ****

On a sunny day (Mon, 14 Jun 2004 20:22:55 GMT) it happened "David W. Fenton"
<dX********@bway.net.invalid> wrote in
<Xn**********************************@24.168.128. 74>:

The EXISTING file comes FIRST.

That rather misses the point, doesn't it?

I.e., why can't the documentation be that clear?

From man ln:

ln [OPTION]... TARGET [LINK_NAME]
ln [OPTION]... TARGET... DIRECTORY
ln [OPTION]... --target-directory=DIRECTORY TARGET...

DESCRIPTION
Create a link to the specified TARGET with optional
LINK_NAME. If LINK_NAME is omitted, a link with the same

What is not clear about that?
JP

Apparently, you have a different man file than I do.

Nov 13 '05 #53

paii, Ron

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.74...

"paii, Ron" <pa**@packairinc.com> wrote in
news:10************@corp.supernews.com:
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.74...
"paii, Ron" <pa**@packairinc.com> wrote in
news:10*************@corp.supernews.com:

> Access is far from perfect and is a resource hog

How, exactly, does Access hog resources?

I run Access on terminal server. It requires a lot of memory and
CPU time for each instance.
Microsoft recommends treating each Access user as a power user
when sizing a Terminal Server.

And how does that compare to Excel or Word? Do you have any actual
numbers?

I can't say it's generally relevant to non-Terminal Server
applications, though.

And it's not especially surprising that an application that does so
much more than Excel or Word would also take more resources --
you're also getting a lot more out of it.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

I have no actual numbers, only my experience. For example we ran a CAD
application on the Terminal server allowing fabrication department to
preview CNC programs. It put less of a load on the server then Access.

Nov 13 '05 #54

David W. Fenton wrote:

Bernd Bollman <be***@hotmail.com> wrote:
[...Microsoft Access...] For a new user
with prior experience in other better designed systems it appears
completely nonsensical.
Please name some better-designed systems

C, C++, Java and lots more.
that are the same kinds of
tools:
I've already stated that I respect the fact that Access provides some
unique features and is of great value to the few who happen to know
it well enough. I did not say that there are better alternatives. All
I said was that its design is total bullshit and its a pain having to
work with it and adapt to its confusing inner workings _if_ you have
had prior experience in a well designed programming environment _and_
you are able to recognize and appreciate the beautifulness of good
structure and desgin if you face it.
Visual Basic is bad-mouthed because anybody can write it.

I have yet to see anyone provide any technical reasons why VB is
subpar in any area (including performance, BTW).

I recommend you take a look at one of the aforementioned languages and
it will open your eyes.

I'd like to know what about the documentation you see as
problematic.

It reflects the (IMO) bad design and opaqueness.

I don't see that, either, so you're just blowing hot air, so far as
I can see. If you can't provide specific examples to support your
assertions, then I feel safe disregarding them.

I dont want to convince you, I was just stating my opinion. You can
think whatever you want, I dont care.

But to not look like a stupid MS-bashing troll Ill show a view of
how it appears to a new user wanting to learn VBA.

Ok, I click "Help"->"Microsof Access help" (sorry if the entries
are named different, Ill try my best translating correctly).
"Programming in Visual Basic" looks good, "Microsoft Access Visual
Basic Reference" too. Im welcome with a graphical overview of the
object hierarchy. So it looks like its an object-oriented language.
Nice. Next come listings of SQL and VBA functions, "Whats new" and...
Oh, "programming concepts" sounds like important basic information.

But what a disappointment. It starts right away with _extended_
concepts, which in turn begins with a discussion of avoidance of
name conflicts with modules, procedures and objects before these
language elements are even briefly described. But okay, its
called "*extended* programming concepts". The following section
has a funny name: "click on activex controls" :)
Of course this and everything else under "programming concepts"
serves no useful purpose for a beginning VBA programmer.

Next in the "Microsoft Visual Basic Reference" come alphabetical
listings of objects, methods, attributes and events. If this
section would be called "Microsoft Visual Basic Class-Hierarchy
Reference" it would make much more sense because the language
proper isnt even remotely touched.

Further down in "Programming in Visual Basic" we have "Microsoft
Office Visual Basic Reference" (which is also duplicated at the
top level). Now whats the difference? From looking at it I cant
tell and it also only provides the same useless object, method
etc. listings as "MS A. VB Reference" does.

The next point is "Visual Basic - Conceptional Topics". Its a
collection of arbitrary but very interesting topics like scope
and lifetime of variables. Sad I dont even know how to declare
one (do I even _have_ to declare it?). Oh, after looking more
closely at this alphabetically sorted (!) list I found "Declaring
variables".

Ok, apparently we have function local, and global variables
which are declared by using "Dim <var> As <type>". "Public"
instead of "Dim" in global declarations provides us with
variables that can be used across modules. Now an overview of
all available types and declaring multiples variables in a single
statement. If we leave out the type it defaults to "Variant".

[experienced programmer stops and thinks for a while about how
the compiler (or interpreter? dont know...) handles variables
that can hold objects of any type and to what code constructs
this could possibly lead]

We also have module local variables by using "Private" instead
of "Dim". Oh, its essentially the same! Now one of them is clearly
superfluous, isnt it? We can also use "Static" instead of "Dim"
to get variables that keep their value between calls. Huh? I can
call a module?

What comes next will scare away any serious hacker if he has
managed to get to this point at all. Variables are implicitely
declared by just using it in a statement (...) and you can even
completely change the meaning of the code by using "Option
Explicit". So there seem to be practically two fundamentally
different syntaxes with the same name - VBA.

I will stop here, I think its enough. This was just a single
section and it goes on like this. I still dont know how the
input text is separated into tokens (if it is at all) and what
are the lexical elements of the language. Can it even be
represented by some formal syntax description language?
And concerning the documentation - its just totally confusing
and very hard to find anything.

Nonetheless, I'll take my "opaque monolithic Monster-Bloatware"
over any of the alternatives any day.

And I'll probably be able to finish the same project in 1/2 or
less the time it would take anyone working on any competing
platform.

May very well be. I would never in my life touch Access again.

Your choice, but that choice mostly seems to based on your own
ignorance of how to use the tool more than it is on any actual
deficiencies in Access, which you seem able to identify in general,
but not in the specific.

I hope I've made my point clear now. And I hope you appreciate
my efforts. You probably dont know how hard it was for me to
start a Windows system, use it, navigate the Access help and
restrain from using animal language in my posting while describing
my experience :)

cheers, Bernd

Nov 13 '05 #55

On Tue, 15 Jun 2004 17:49:24 +0200, Bernd Bollman <be***@hotmail.com> wrote:

David W. Fenton wrote:
Bernd Bollman <be***@hotmail.com> wrote:
> [...Microsoft Access...] For a new user
> with prior experience in other better designed systems it appears
> completely nonsensical.
Please name some better-designed systems

C, C++, Java and lots more.

C and C++ - better designed for what? For writing drivers, yeah, good tools.
For business apps, they just give you more ways to introduce worse bugs into
your programs. Java - you could argue the point, but the GUI designers and
components are not (yet) up to par with Access, and certanly not when lots of
binding to database data is involved. Furthermore, unlike Access, our
non-programmer users can't do minor maintenance themselves with Java like they
can with Access.

With Access, any form I create in my application gives users all the power of
an Access form. Users can filter and sort on anything, they can add and
delete rows, then can copy and paste, do spell check etc. In any other GUI
toolkit I know of, I have to design a way of implementing those features
myself, and make it work on each form.

Also, many of our clients have been able to prototype applications that do 80%
of what they need, and just want some bullet proofing and extra features.
They don't want a rewrite. Or, if we're starting from scratch, our clients
value the fact that the non-programmer manager can add a couple of fields to a
table, and add them to a form or report himself.

Finally, the Access report writer has features nothing else has, it's
integrated into the IDE, and its object model significantly overlaps the
Access form object model to the point where you can copy and paste UI elements
between the 2 or print a form as if it was a report.

that are the same kinds of
tools:
I've already stated that I respect the fact that Access provides some
unique features and is of great value to the few who happen to know
it well enough. I did not say that there are better alternatives. All
I said was that its design is total bullshit and its a pain having to
work with it and adapt to its confusing inner workings _if_ you have
had prior experience in a well designed programming environment _and_
you are able to recognize and appreciate the beautifulness of good
structure and desgin if you face it.

The Access event model is great. Its language is not great, but not the worst
that people are using. Its OOP features are pretty poor, but you mentioned C
which has no OOP features at all. The deficiencies the language does have are
greatly outweighed by the power and appropriateness of the UI environment and
object/event model. Would I like something like Access with C# or Java or
even Python as the programming language, possibly with UO object inheritance
like Delphi? You bet, but what I have is the best fit for what I do that is
currently available.

Visual Basic is bad-mouthed because anybody can write it.

I have yet to see anyone provide any technical reasons why VB is
subpar in any area (including performance, BTW).

I recommend you take a look at one of the aforementioned languages and
it will open your eyes.

I programmed in C and C++ as a hoobyist for a long time. While an expert may
be able to write decent code quickly in those languages, they don't provide
any obvious benefit for business applications, and they provide a lot of ways
to shoot yourself in the foot. Java - OK, you can use that for business apps,
but again, even if I was an expert, I don't think I could be nearly as
productive writing data-centric apps in Java, and my customers wouldn't get
the value added of the Access UI components nor the ability to do simple
maintenance themselves without programmer assistance.

>> I'd like to know what about the documentation you see as
>> problematic.
>
> It reflects the (IMO) bad design and opaqueness.

I don't see that, either, so you're just blowing hot air, so far as
I can see. If you can't provide specific examples to support your
assertions, then I feel safe disregarding them.

I dont want to convince you, I was just stating my opinion. You can
think whatever you want, I dont care.

But to not look like a stupid MS-bashing troll Ill show a view of
how it appears to a new user wanting to learn VBA.

Ok, I click "Help"->"Microsof Access help" (sorry if the entries
are named different, Ill try my best translating correctly).
"Programming in Visual Basic" looks good, "Microsoft Access Visual
Basic Reference" too. Im welcome with a graphical overview of the
object hierarchy. So it looks like its an object-oriented language.
Nice. Next come listings of SQL and VBA functions, "Whats new" and...
Oh, "programming concepts" sounds like important basic information.

But what a disappointment. It starts right away with _extended_
concepts, which in turn begins with a discussion of avoidance of
name conflicts with modules, procedures and objects before these
language elements are even briefly described. But okay, its
called "*extended* programming concepts". The following section
has a funny name: "click on activex controls" :)
Of course this and everything else under "programming concepts"
serves no useful purpose for a beginning VBA programmer.

The help is mainly a reference to look things up. The manual is a different
thing and is in Books Online, not in Help.

....Ok, apparently we have function local, and global variables
which are declared by using "Dim <var> As <type>". "Public"
instead of "Dim" in global declarations provides us with
variables that can be used across modules. Now an overview of
all available types and declaring multiples variables in a single
statement. If we leave out the type it defaults to "Variant".

[experienced programmer stops and thinks for a while about how
the compiler (or interpreter? dont know...) handles variables
that can hold objects of any type and to what code constructs
this could possibly lead]
Experienced programmers disagree on whether type safety is a good thing or a
bad thing. In database programming, the lack of it is often a useful thing
because you may need to copy values of fields around before you know what
primitive type they are - or whether they contain Null. Many experienced
programmers extol the virtues of Smalltalk which has no variable typeing at
all - it's completely type-unsafe. That's OK, they say, because your unit
tests should catch most errors.
We also have module local variables by using "Private" instead
of "Dim". Oh, its essentially the same! Now one of them is clearly
superfluous, isnt it? We can also use "Static" instead of "Dim"
to get variables that keep their value between calls. Huh? I can
call a module?

Yes, VBA has oddities that take some time to get used to. Most languages do.
If you read the books online, however, it all does get explained fairly well.
What comes next will scare away any serious hacker if he has
managed to get to this point at all. Variables are implicitely
declared by just using it in a statement (...) and you can even
completely change the meaning of the code by using "Option
Explicit". So there seem to be practically two fundamentally
different syntaxes with the same name - VBA.
I have to grant you that one. There is no excuse to ever write code without
Option Explicit, and it's the default setting to not have it. The fisrt thing
I do when looking t code written by a newby VBA programmer is add Option
Explicit everywhere, compile, and fix all the errors - and there are usually
some serious bugs to fix. The reason for the non-explicit option is a dubious
attempt to remain somewhat compatible with BASIC.
I will stop here, I think its enough. This was just a single
section and it goes on like this. I still dont know how the
input text is separated into tokens (if it is at all) and what
are the lexical elements of the language. Can it even be
represented by some formal syntax description language?
And concerning the documentation - its just totally confusing
and very hard to find anything.

Similar complaints can be made of many language. More complaints about some,
and fewer about others. Wanna get me started on operator overloading in C++,
ore the wisdom of allowing case-specific names?

>> Nonetheless, I'll take my "opaque monolithic Monster-Bloatware"
>> over any of the alternatives any day.
>>
>> And I'll probably be able to finish the same project in 1/2 or
>> less the time it would take anyone working on any competing
>> platform.
>
> May very well be. I would never in my life touch Access again.

Your choice, but that choice mostly seems to based on your own
ignorance of how to use the tool more than it is on any actual
deficiencies in Access, which you seem able to identify in general,
but not in the specific.

I hope I've made my point clear now. And I hope you appreciate
my efforts. You probably dont know how hard it was for me to
start a Windows system, use it, navigate the Access help and
restrain from using animal language in my posting while describing
my experience :)

Well, I can respect that, and I'm sure much of it is just the devil you know
vs the devil you don't. I can tell you, though, that trying to go the other
way, from an integrated IDE that's made specifically for highly usable
database apps on an OS we're familliar with to adding all the features
manually to our UI model (those within reason to do manuall) on an OS that we
frequently can't even get to install with packaging systems that don't give us
a clue what components we need is also a seriously scary and difficult
exercise.

Nov 13 '05 #56

In message <ca*************@news.t-online.com>, Bernd Bollman
<be***@hotmail.com> writes

David W. Fenton wrote:
Bernd Bollman <be***@hotmail.com> wrote:
> [...Microsoft Access...] For a new user
> with prior experience in other better designed systems it appears
> completely nonsensical.
Please name some better-designed systems

C, C++, Java and lots more.

None of the three languages you list would be suitable as a replacement
for VBA in Access although all three have their uses.

One of the design features in Access and other end-user tools is that
the macro language has to be reasonably easily understandable by people
who have little or no training in programming. Just one example, the for
loop structure in C wouldn't be acceptable in an application like
Access.

I know that there has been some recent debate about the future of VBA.
It looks likely that when .NET is fully integrated into Office it will
be possible to write macros in any .NET language. Won't that be fun?
Imagine supporting an app where the source code is a mixture of C++, C#,
VB and Java depending on which user was developing it.

that are the same kinds of
tools:

I've already stated that I respect the fact that Access provides some
unique features and is of great value to the few who happen to know
it well enough. I did not say that there are better alternatives. All
I said was that its design is total bullshit and its a pain having to
work with it and adapt to its confusing inner workings _if_ you have
had prior experience in a well designed programming environment _and_
you are able to recognize and appreciate the beautifulness of good
structure and desgin if you face it.
Visual Basic is bad-mouthed because anybody can write it.

I have yet to see anyone provide any technical reasons why VB is
subpar in any area (including performance, BTW).

I recommend you take a look at one of the aforementioned languages and
it will open your eyes.

I have written code in a dozen different languages including FORTRAN,
COBOL and C. Each of them has its place. If I was adapting an existing
language to a system like Access and wasn't able to use BASIC I would
probably choose COBOL as the best one for the purpose.

I'm not saying that COBOL is a good general purpose language but it does
have some features that
--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author. Will work for money.

Nov 13 '05 #57

Steve

On Tue, 15 Jun 2004 16:45:16 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:

Great response.

<snip>

With Access, any form I create in my application gives users all the power of
an Access form. Users can filter and sort on anything, they can add and
delete rows, then can copy and paste, do spell check etc. In any other GUI
toolkit I know of, I have to design a way of implementing those features
myself, and make it work on each form.
I hate the fact that the runtime does not have filtering by form.
Never understood if there were technical reasons; or is this just a
marketing ploy to encourage the purchase of the full product.

<snip>
The Access event model is great. Its language is not great, but not the worst
that people are using. Its OOP features are pretty poor, but you mentioned C
which has no OOP features at all. The deficiencies the language does have are
greatly outweighed by the power and appropriateness of the UI environment and
object/event model. Would I like something like Access with C# or Java or
even Python as the programming language, possibly with UO object inheritance
like Delphi? You bet, but what I have is the best fit for what I do that is
currently available.
Access is great for consuming objects. How many of us really need OOP
to create objects in Access?

Let's see what happens with VB.Net and Access for future OOP
development.

<snip>
I have to grant you that one. There is no excuse to ever write code without
Option Explicit, and it's the default setting to not have it. The fisrt thing
I do when looking t code written by a newby VBA programmer is add Option
Explicit everywhere, compile, and fix all the errors - and there are usually
some serious bugs to fix. The reason for the non-explicit option is a dubious
attempt to remain somewhat compatible with BASIC.

But it is so easy to check the default "require variable declarations"
option on.

I agree with your defense of Access. So much complaining about
Access; but very few products that can really compete with it for
database centric RAD applications.

Steven

Nov 13 '05 #58

"paii, Ron" <pa**@packairinc.com> wrote in
news:10*************@corp.supernews.com:

I have no actual numbers, only my experience. For example we ran a
CAD application on the Terminal server allowing fabrication
department to preview CNC programs. It put less of a load on the
server then Access.

Well, without any numbers, it's quite uncleare what that load might
have been.

Any number of things could have been involved that have nothing
whatsoever to do with Access itself and instead have to do with the
design of your particular Access application, or of the environment
in which you were running it.

Absent any facts, I can't say that I give the assertion that Access
is a resource hog much credence.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #59

Bernd Bollman <be***@hotmail.com> wrote in
news:ca*************@news.t-online.com:

David W. Fenton wrote:
Bernd Bollman <be***@hotmail.com> wrote:
> [...Microsoft Access...] For a new user
> with prior experience in other better designed systems it
> appears completely nonsensical.
Please name some better-designed systems

C, C++, Java and lots more.

These are not RAD database application development systems that can
also be used as an end-user tool.

The design reflects the purpose of the product. Comparing designs of
products with entirely different purposes is completely fruitless.
You wouldn't fault the design of a BMW convertible because it lacks
the horsepower of a Mack truck.

Unless you're an idiot.

that are the same kinds of
tools:

I've already stated that I respect the fact that Access provides
some unique features and is of great value to the few who happen
to know it well enough. I did not say that there are better
alternatives. All I said was that its design is total
bullshit . . .

And yet, you can't give a single example of the "bullshit design"
that holds up under any scrutiny whatsoever.
. . . and
its a pain having to work with it and adapt to its confusing inner
workings . . .
This is how I feel about Linux.
. . . _if_ you have had prior experience in a well designed
programming environment . . .
I know a number of programmers who have wide experience in a number
of development platforms who have found using Access really easy.
Maybe that's because they left their baggage at the door and took
Access for what it is, instead of trying to make it be like the
platforms they are experienced with.
. . . _and_ you are able to recognize and
appreciate the beautifulness of good structure and desgin if you
face it.
Thanks for the thinly veiled insult.

Visual Basic is bad-mouthed because anybody can write it.

I have yet to see anyone provide any technical reasons why VB is
subpar in any area (including performance, BTW).

I recommend you take a look at one of the aforementioned languages
and it will open your eyes.

First, they are designed for completely different purposes.

D'oh.

So, they will have different architectures.

Second, VB is not VBA and VBA is not VBA as used in Access. VBA in
Access is used very specifically in its purpose as the programming
language for building database applications. In that context, it's
very easy to use and very efficient.

For the purpose it is designed to be used.

>> I'd like to know what about the documentation you see as
>> problematic.
>
> It reflects the (IMO) bad design and opaqueness.

I don't see that, either, so you're just blowing hot air, so far
as I can see. If you can't provide specific examples to support
your assertions, then I feel safe disregarding them.

I dont want to convince you, I was just stating my opinion. You
can think whatever you want, I dont care.

Well, f all you're interested in is saying how awful Access is, then
please, take comp.databases.ms-access out of the followups.
But to not look like a stupid MS-bashing troll Ill show a view of
how it appears to a new user wanting to learn VBA.

Ok, I click "Help"->"Microsof Access help" (sorry if the entries
are named different, Ill try my best translating correctly).
"Programming in Visual Basic" looks good, "Microsoft Access Visual
Basic Reference" too. . . .
Well, stop right there.

Why aren't you instead investigating the sample databases?
. . . Im welcome with a graphical overview of the
object hierarchy. So it looks like its an object-oriented
language. Nice. Next come listings of SQL and VBA functions,
"Whats new" and... Oh, "programming concepts" sounds like
important basic information.
Except you're going at things completely backwards for a RAD
development tool. You should instead start by looking at the table,
form and report design features, where you can build basic objects
without writing code. *Then* you can extend those objects with code
that expands on the default behaviors of those objects.
But what a disappointment. It starts right away with _extended_
concepts, which in turn begins with a discussion of avoidance of
name conflicts with modules, procedures and objects before these
language elements are even briefly described. . . .
You started at the wrong end, asking "how do I program?" instead of
"how do I create a database application?"
. . . But okay, its
called "*extended* programming concepts". The following section
has a funny name: "click on activex controls" :)
Of course this and everything else under "programming concepts"
serves no useful purpose for a beginning VBA programmer.
Well, your mental model of what the product is for is wrong. Hence,
you end up looking in the wrong places for Help.
Next in the "Microsoft Visual Basic Reference" come alphabetical
listings of objects, methods, attributes and events. If this
section would be called "Microsoft Visual Basic Class-Hierarchy
Reference" it would make much more sense because the language
proper isnt even remotely touched.

Further down in "Programming in Visual Basic" we have "Microsoft
Office Visual Basic Reference" (which is also duplicated at the
top level). Now whats the difference? From looking at it I cant
tell and it also only provides the same useless object, method
etc. listings as "MS A. VB Reference" does.

The next point is "Visual Basic - Conceptional Topics". Its a
collection of arbitrary but very interesting topics like scope
and lifetime of variables. Sad I dont even know how to declare
one (do I even _have_ to declare it?). Oh, after looking more
closely at this alphabetically sorted (!) list I found "Declaring
variables".

Ok, apparently we have function local, and global variables
which are declared by using "Dim <var> As <type>". "Public"
instead of "Dim" in global declarations provides us with
variables that can be used across modules. Now an overview of
all available types and declaring multiples variables in a single
statement. If we leave out the type it defaults to "Variant".

[experienced programmer stops and thinks for a while about how
the compiler (or interpreter? dont know...) handles variables
that can hold objects of any type and to what code constructs
this could possibly lead]
Late binding vs. early binding. I'm not sure that's covered in the
help file, which always gives examples using early binding, so far
as I can tell.

This is an advanced question that has very little to do with the
task of building database applications.

It's a programmer's question, instead.
We also have module local variables by using "Private" instead
of "Dim". Oh, its essentially the same! Now one of them is clearly
superfluous, isnt it? We can also use "Static" instead of "Dim"
to get variables that keep their value between calls. Huh? I can
call a module?

What comes next will scare away any serious hacker if he has
managed to get to this point at all. Variables are implicitely
declared by just using it in a statement (...) and you can even
completely change the meaning of the code by using "Option
Explicit". So there seem to be practically two fundamentally
different syntaxes with the same name - VBA.
No, there's two different ways of using it, with Option Explicit,
which requires variable declaration (the default until Access 2000,
when MS stupidly sacrificed the features of the Access VBA editor in
order to make it work the same as the VBE (Environment) used in
other MS Office programs; in other words, they made the IDE for the
most advanced of their products like the simplified IDE that is used
in their less advanced products; yes, we probably agree this was a
really stupid decision; in the next version of Access, they changed
the default back to using Option Explicit), and without it.

The default in Word and Excel macros is to not require explicit
variable declaration. VBScript works this way, too.

My first db language was Paradox's PAL, and it worked that way, too.
That's why I was thrilled when I started using Access that I could
make sure that my code required variable declaration.
I will stop here, I think its enough. This was just a single
section and it goes on like this. I still dont know how the
input text is separated into tokens (if it is at all) and what
are the lexical elements of the language. Can it even be
represented by some formal syntax description language?
And concerning the documentation - its just totally confusing
and very hard to find anything.
Why do you care about these things at this point?

You're asking entirely the wrong question.

It's like taking a manual for a radio and trying to figure out from
it how the batteries work, instead of wanting to figure out how to
play some tunes.

>> Nonetheless, I'll take my "opaque monolithic
>> Monster-Bloatware" over any of the alternatives any day.
>>
>> And I'll probably be able to finish the same project in 1/2 or
>> less the time it would take anyone working on any competing
>> platform.
>
> May very well be. I would never in my life touch Access again.

Your choice, but that choice mostly seems to based on your own
ignorance of how to use the tool more than it is on any actual
deficiencies in Access, which you seem able to identify in
general, but not in the specific.

I hope I've made my point clear now. . ..

You've made it abundantly clear that you have little comprehension
of what a tool like Access was created to accomplish.
. . . And I hope you appreciate
my efforts. You probably dont know how hard it was for me to
start a Windows system, use it, navigate the Access help and
restrain from using animal language in my posting while describing
my experience :)

Well, have some sympathy for those who try to use Linux, which has a
different set of metaphors and paradigms and has documentation that
seems to me to be written for people who already know the answers.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #60

Steve Jorgensen <no****@nospam.nospam> wrote in
news:tm********************************@4ax.com:

There is no excuse to ever write code without
Option Explicit, and it's the default setting to not have it.

Wasn't this changed back in A2K2 or A2K3 to default to having it on?

Or was that just including the DAO reference along with the useless
ADO reference?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #61

In message <Xn**********************************@24.168.128.7 8>, David
W. Fenton <dX********@bway.net.invalid> writes

Bernd Bollman <be***@hotmail.com> wrote in
news:ca*************@news.t-online.com:
David W. Fenton wrote:
Bernd Bollman <be***@hotmail.com> wrote:
> [...Microsoft Access...] For a new user
> with prior experience in other better designed systems it
> appears completely nonsensical.

Please name some better-designed systems
C, C++, Java and lots more.

These are not RAD database application development systems that can
also be used as an end-user tool.

We were discussing programming languages within the IDE rather than the
IDE itself. I don't see any inherent reason why any of these languages
couldn't be used within a system like Access. I don't think it would be
a good IDE, but that's a separate issue.

The design reflects the purpose of the product. Comparing designs of
products with entirely different purposes is completely fruitless.
You wouldn't fault the design of a BMW convertible because it lacks
the horsepower of a Mack truck.

Unless you're an idiot.
I don't think Bernd is an idiot but I do think he is seriously mistaken
if he believes that any of those languages would be an improvement over
VBA within Access. That's probably because he is approaching this from
the point of view of a programmer. Although Access can be used by
programmers they are probably the minority of users, and not really the
people Access is targeted at.

[...]

. . . _and_ you are able to recognize and
appreciate the beautifulness of good structure and desgin if you
face it.

Thanks for the thinly veiled insult.

I didn't see that as an insult myself.

[...]

I dont want to convince you, I was just stating my opinion. You
can think whatever you want, I dont care.

Well, f all you're interested in is saying how awful Access is, then
please, take comp.databases.ms-access out of the followups.
But to not look like a stupid MS-bashing troll Ill show a view of
how it appears to a new user wanting to learn VBA.

Ok, I click "Help"->"Microsof Access help" (sorry if the entries
are named different, Ill try my best translating correctly).
"Programming in Visual Basic" looks good, "Microsoft Access Visual
Basic Reference" too. . . .

Well, stop right there.

Why aren't you instead investigating the sample databases?

I agree with you here. I have no idea why anyone would attempt to learn
Access by reading the manual. No real users is likely (cue chorus of "We
did!") to start out that way. If they have enough experience with
Windows programs they will just start working through the menus, if they
haven't they will probably start by buying a book on Access and working
through it.

As a technical author I like to see a good healthy layer of dust on the
user manuals, it means the software is usable without them. Good
software is like that.

. . . Im welcome with a graphical overview of the
object hierarchy. So it looks like its an object-oriented
language. Nice. Next come listings of SQL and VBA functions,
"Whats new" and... Oh, "programming concepts" sounds like
important basic information.

Except you're going at things completely backwards for a RAD
development tool. You should instead start by looking at the table,
form and report design features, where you can build basic objects
without writing code. *Then* you can extend those objects with code
that expands on the default behaviors of those objects.

Agreed. Build applications without any coding and then when you are
happy with that start by recording some macros and looking at the code
they produce. Tweak the code a little and watch it break!

--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author. Will work for money.

Nov 13 '05 #62

Steve Jorgensen wrote:

On Tue, 15 Jun 2004 17:49:24 +0200, Bernd Bollman <be***@hotmail.com> wrote:
David W. Fenton wrote:
Bernd Bollman <be***@hotmail.com> wrote:
> [...Microsoft Access...] For a new user
> with prior experience in other better designed systems it appears
> completely nonsensical.

Please name some better-designed systems

C, C++, Java and lots more.

C and C++ - better designed for what? For writing drivers, yeah, good tools.
For business apps, they just give you more ways to introduce worse bugs into
your programs. Java - you could argue the point, but the GUI designers and
components are not (yet) up to par with Access, and certanly not when lots of
binding to database data is involved. Furthermore, unlike Access, our
non-programmer users can't do minor maintenance themselves with Java like they
can with Access.

With Access, any form I create in my application gives users all the power of
an Access form. Users can filter and sort on anything, they can add and
delete rows, then can copy and paste, do spell check etc. In any other GUI
toolkit I know of, I have to design a way of implementing those features
myself, and make it work on each form.

Also, many of our clients have been able to prototype applications that do 80%
of what they need, and just want some bullet proofing and extra features.
They don't want a rewrite. Or, if we're starting from scratch, our clients
value the fact that the non-programmer manager can add a couple of fields to a
table, and add them to a form or report himself.

Finally, the Access report writer has features nothing else has, it's
integrated into the IDE, and its object model significantly overlaps the
Access form object model to the point where you can copy and paste UI elements
between the 2 or print a form as if it was a report.

There is a big misunderstanding here. I am *not* saying that there are
better tools that can do what Access can do. We were *only* talking
about the design and that *I* think Access's is not quite perfect, to
say the least ;)

>> I'd like to know what about the documentation you see as
>> problematic.

[rant about Access docs]

The help is mainly a reference to look things up. The manual is a different
thing and is in Books Online, not in Help.

That may be but we were discussing the Access documentation.

I hope I've made my point clear now. And I hope you appreciate
my efforts. You probably dont know how hard it was for me to
start a Windows system, use it, navigate the Access help and
restrain from using animal language in my posting while describing
my experience :)

Well, I can respect that, and I'm sure much of it is just the devil you know
vs the devil you don't. I can tell you, though, that trying to go the other
way, from an integrated IDE that's made specifically for highly usable
database apps on an OS we're familliar with to adding all the features
manually to our UI model (those within reason to do manuall) on an OS that we
frequently can't even get to install with packaging systems that don't give us
a clue what components we need is also a seriously scary and difficult
exercise.

I absolutely believe you. I dont want to stop you from using Access.
Really.

cheers, Bernd

Nov 13 '05 #63

Bernard Peek wrote:

In message <ca*************@news.t-online.com>, Bernd Bollman
<be***@hotmail.com> writes
David W. Fenton wrote:
Bernd Bollman <be***@hotmail.com> wrote:
> [...Microsoft Access...] For a new user
> with prior experience in other better designed systems it appears
> completely nonsensical.

Please name some better-designed systems

C, C++, Java and lots more.

None of the three languages you list would be suitable as a replacement
for VBA in Access

And I did not claim they are. The discussion is just about good vs.
bad design of programming environments.

cheers, Bernd

Nov 13 '05 #64

Bernard Peek <ba*@shrdlu.com> wrote in
news:TU**************@shrdlu.com:

In message <Xn**********************************@24.168.128.7 8>,
David W. Fenton <dX********@bway.net.invalid> writes
Bernd Bollman <be***@hotmail.com> wrote in
news:ca*************@news.t-online.com:
David W. Fenton wrote:
Bernd Bollman <be***@hotmail.com> wrote:
> [...Microsoft Access...] For a new user
> with prior experience in other better designed systems it
> appears completely nonsensical.

Please name some better-designed systems

C, C++, Java and lots more.
These are not RAD database application development systems that
can also be used as an end-user tool.

We were discussing programming languages within the IDE rather
than the IDE itself. . ..

Yes, and, therefore, you're evaluating the languages in the wrong
context.
. . . I don't see any inherent reason why any of
these languages couldn't be used within a system like Access. I
don't think it would be a good IDE, but that's a separate issue.
The languages would require an enormous amount of extension, perhaps
accomplished through large custom class libraries, to come even
close to the flexibility available in VBA.

The design reflects the purpose of the product. Comparing designs
of products with entirely different purposes is completely
fruitless. You wouldn't fault the design of a BMW convertible
because it lacks the horsepower of a Mack truck.

Unless you're an idiot.

I don't think Bernd is an idiot but I do think he is seriously
mistaken if he believes that any of those languages would be an
improvement over VBA within Access. That's probably because he is
approaching this from the point of view of a programmer. Although
Access can be used by programmers they are probably the minority
of users, and not really the people Access is targeted at.

Well, I *am* an Access programmer, and I have yet to see a serious
critique of Access from a language standpoint that does not reflect
a complete lack of any real understanding of the problem space VBA
was implemented for.

[]

But to not look like a stupid MS-bashing troll Ill show a view
of how it appears to a new user wanting to learn VBA.

Ok, I click "Help"->"Microsof Access help" (sorry if the entries
are named different, Ill try my best translating correctly).
"Programming in Visual Basic" looks good, "Microsoft Access
Visual Basic Reference" too. . . .

Well, stop right there.

Why aren't you instead investigating the sample databases?

I agree with you here. I have no idea why anyone would attempt to
learn Access by reading the manual. . . .

It's not reading the manual that's the issue. It's starting with
trying to learn the programming language without having learned how
to use Access itself first.
. . . No real users is likely (cue
chorus of "We did!") to start out that way. If they have enough
experience with Windows programs they will just start working
through the menus, if they haven't they will probably start by
buying a book on Access and working through it.

As a technical author I like to see a good healthy layer of dust
on the user manuals, it means the software is usable without them.
Good software is like that.

Yep! I agree!

On the other hand, there's easy to learn and there's easy to use.
The two are often mutually contradictory goals -- UIs that are easy
to learn often get in the way once you know how to do your job
(e.g., wizard interfaces), whereas UIs that are very fast and
flexible for the knowledgeable are often completely opaque to the
uninitiated (function-key UIs, like classic WordPerfect, or CLIs).

I try to design my application interfaces to be easy to use once
you've had a little introduction to how it works. Generally, 30
minutes of training is all that's necessary with my apps (though
some users need to have their 30 minutes several times. . .).

. . . Im welcome with a graphical overview of the
object hierarchy. So it looks like its an object-oriented
language. Nice. Next come listings of SQL and VBA functions,
"Whats new" and... Oh, "programming concepts" sounds like
important basic information.

Except you're going at things completely backwards for a RAD
development tool. You should instead start by looking at the
table, form and report design features, where you can build basic
objects without writing code. *Then* you can extend those objects
with code that expands on the default behaviors of those objects.

Agreed. Build applications without any coding and then when you
are happy with that start by recording some macros and looking at
the code they produce. Tweak the code a little and watch it break!

Well, there's no macro recording in Access (I've always wished there
were, but I think it's because there's too little predictability in
custom-designed interfaces), but I learned Access by starting with
the things I could do without code, and then learned what code I
needed to change behaviors I didn't like.

That's the point of RAD -- you don't have to code everything, only
the things that are unusual about your approach to solving problems.

I have some problems with a number of the methods the Access
documentation and sample databases encourage, but Access doesn't get
in my way in avoiding the problems there.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #65

David W. Fenton wrote:

Bernd Bollman <be***@hotmail.com> wrote in
news:ca*************@news.t-online.com:
David W. Fenton wrote:
Bernd Bollman <be***@hotmail.com> wrote:
> [...Microsoft Access...] For a new user
> with prior experience in other better designed systems it
> appears completely nonsensical.

Please name some better-designed systems
C, C++, Java and lots more.

These are not RAD database application development systems that can
also be used as an end-user tool.

We were not talking about RAD database development. At least *I* was
not. Sorry if I was vague.
The design reflects the purpose of the product. Comparing designs of
products with entirely different purposes is completely fruitless.
You wouldn't fault the design of a BMW convertible because it lacks
the horsepower of a Mack truck.
Youre right, that would be senseless. But assuming you know a bit
about cars you could look at each one seperately and decide if its
design makes sense for its chosen purpose.

I've already stated that I respect the fact that Access provides
some unique features and is of great value to the few who happen
to know it well enough. I did not say that there are better
alternatives. All I said was that its design is total
bullshit . . .

And yet, you can't give a single example of the "bullshit design"
that holds up under any scrutiny whatsoever.

I suspect you haven't read the rest of my post yet when you wrote
this.

. . . and
its a pain having to work with it and adapt to its confusing inner
workings . . .

This is how I feel about Linux.

Ok, I fully respect that.

. . . _if_ you have had prior experience in a well designed
programming environment . . .

I know a number of programmers who have wide experience in a number
of development platforms who have found using Access really easy.
Maybe that's because they left their baggage at the door and took
Access for what it is, instead of trying to make it be like the
platforms they are experienced with.

I grant everyone to decide for himself what he likes and what not.
Those people and you like Access, I do not and Ive explained why.

. . . _and_ you are able to recognize and
appreciate the beautifulness of good structure and desgin if you
face it.

Thanks for the thinly veiled insult.

Im really sorry if anybody felt insulted by me (Im not a native
English speaker). It was not my intent. I wanted to express
something like "if you actually care about design". The opposite
would be: "I dont care about the design, and as long as it works
and I can do what I want it to do it can be ugly as butt".

Visual Basic is bad-mouthed because anybody can write it.

I have yet to see anyone provide any technical reasons why VB is
subpar in any area (including performance, BTW).

I recommend you take a look at one of the aforementioned languages
and it will open your eyes.

First, they are designed for completely different purposes.

D'oh.

So, they will have different architectures.

No, they are all programming languages with variables, statements,
functions and the like. Of course VBA is used primarily for
extending Office programs but you can perfectly compare the basic
language structure because these things are used the same way in
all languages.
Second, VB is not VBA and VBA is not VBA as used in Access. VBA in
Access is used very specifically in its purpose as the programming
language for building database applications. In that context, it's
very easy to use and very efficient.

I didnt doubt that. All I say is that I find it ugly.

>> I'd like to know what about the documentation you see as
>> problematic.
>
> It reflects the (IMO) bad design and opaqueness.

I don't see that, either, so you're just blowing hot air, so far
as I can see. If you can't provide specific examples to support
your assertions, then I feel safe disregarding them.

I dont want to convince you, I was just stating my opinion. You
can think whatever you want, I dont care.

Well, f all you're interested in is saying how awful Access is, then
please, take comp.databases.ms-access out of the followups.

Yes, all I wanted to say is how awful Access is. While I have to
admit that this initial posting was really unnecessary (sorry for
that), it was actually *you* asking me for explanation.

But to not look like a stupid MS-bashing troll Ill show a view of
how it appears to a new user wanting to learn VBA.

Ok, I click "Help"->"Microsof Access help" (sorry if the entries
are named different, Ill try my best translating correctly).
"Programming in Visual Basic" looks good, "Microsoft Access Visual
Basic Reference" too. . . .

Well, stop right there.

Why aren't you instead investigating the sample databases?

Im not that kind of guy. I usually learn new languages by some kind
of reference documentation. Furthermore we were talking about the
docs (again it was you who wanted to know what I find problematic).

. . . Im welcome with a graphical overview of the
object hierarchy. So it looks like its an object-oriented
language. Nice. Next come listings of SQL and VBA functions,
"Whats new" and... Oh, "programming concepts" sounds like
important basic information.

Except you're going at things completely backwards for a RAD
development tool. You should instead start by looking at the table,
form and report design features, where you can build basic objects
without writing code. *Then* you can extend those objects with code
that expands on the default behaviors of those objects.
But what a disappointment. It starts right away with _extended_
concepts, which in turn begins with a discussion of avoidance of
name conflicts with modules, procedures and objects before these
language elements are even briefly described. . . .

You started at the wrong end, asking "how do I program?" instead of
"how do I create a database application?"

Hu? You want to prescribe the specific parts that Im allowed to
criticize?

Ok, apparently we have function local, and global variables
which are declared by using "Dim <var> As <type>". "Public"
instead of "Dim" in global declarations provides us with
variables that can be used across modules. Now an overview of
all available types and declaring multiples variables in a single
statement. If we leave out the type it defaults to "Variant".

[experienced programmer stops and thinks for a while about how
the compiler (or interpreter? dont know...) handles variables
that can hold objects of any type and to what code constructs
this could possibly lead]

Late binding vs. early binding. I'm not sure that's covered in the
help file, which always gives examples using early binding, so far
as I can tell.

This is an advanced question that has very little to do with the
task of building database applications.

It's a programmer's question, instead.

VBA is an integral part of developing Access applications, isnt it?

We also have module local variables by using "Private" instead
of "Dim". Oh, its essentially the same! Now one of them is clearly
superfluous, isnt it? We can also use "Static" instead of "Dim"
to get variables that keep their value between calls. Huh? I can
call a module?

What comes next will scare away any serious hacker if he has
managed to get to this point at all. Variables are implicitely
declared by just using it in a statement (...) and you can even
completely change the meaning of the code by using "Option
Explicit". So there seem to be practically two fundamentally
different syntaxes with the same name - VBA.

No, there's two different ways of using it,

Which results in two different languages. By activating a single
switch you can invalidate huge amounts of code.

I will stop here, I think its enough. This was just a single
section and it goes on like this. I still dont know how the
input text is separated into tokens (if it is at all) and what
are the lexical elements of the language. Can it even be
represented by some formal syntax description language?
And concerning the documentation - its just totally confusing
and very hard to find anything.

Why do you care about these things at this point?

You're asking entirely the wrong question.

It's like taking a manual for a radio and trying to figure out from
it how the batteries work, instead of wanting to figure out how to
play some tunes.

No, its like taking an application development environment and trying
to figure out how to progam in it.

>> Nonetheless, I'll take my "opaque monolithic
>> Monster-Bloatware" over any of the alternatives any day.
>>
>> And I'll probably be able to finish the same project in 1/2 or
>> less the time it would take anyone working on any competing
>> platform.
>
> May very well be. I would never in my life touch Access again.

Your choice, but that choice mostly seems to based on your own
ignorance of how to use the tool more than it is on any actual
deficiencies in Access, which you seem able to identify in
general, but not in the specific.

I hope I've made my point clear now. . ..

You've made it abundantly clear that you have little comprehension
of what a tool like Access was created to accomplish.

I think I know quite exactly what Access is.

. . . And I hope you appreciate
my efforts. You probably dont know how hard it was for me to
start a Windows system, use it, navigate the Access help and
restrain from using animal language in my posting while describing
my experience :)

Well, have some sympathy for those who try to use Linux, which has a
different set of metaphors and paradigms and has documentation that
seems to me to be written for people who already know the answers.

They have my fullest sympathy. At least they try ;)

cheers, Bernd

Nov 13 '05 #66

Bernard Peek wrote:

I don't think Bernd is an idiot but I do think he is seriously mistaken
if he believes that any of those languages would be an improvement over
VBA within Access.
I dont believe this. I was merely stating my opinion about it without
providing a better alternative.
I agree with you here. I have no idea why anyone would attempt to learn
Access by reading the manual. No real users is likely (cue chorus of "We
did!") to start out that way. If they have enough experience with
Windows programs they will just start working through the menus,

But some day you may want or need to hack the code and therefore need
to learn the programming language.

cheers, Bernd

Nov 13 '05 #67

David W. Fenton wrote:

Well, I *am* an Access programmer, and I have yet to see a serious
critique of Access from a language standpoint

That saying after you read and replied to my extensive explanations?
Excuse me but I slowly start to think that you are a MS-paid troll.

I agree with you here. I have no idea why anyone would attempt to
learn Access by reading the manual. . . .

It's not reading the manual that's the issue. It's starting with
trying to learn the programming language without having learned how
to use Access itself first.

What the hell!? VBA is an essential part of Access and it can be
studied isolated from supergenious complete-form-with-all-bells-
and-whistles-creating Wizards and the like.

I give up...

Nov 13 '05 #68

Larry Linson

"Bernd Bollman" wrote

David W. Fenton wrote:

Well, I *am* an Access programmer, and
I have yet to see a serious critique of Access
from a language standpoint

That saying after you read and replied to my
extensive explanations? Excuse me but I slowly
start to think that you are a MS-paid troll.

"Extensive explanations"? You lost your credibility when you included C in
that list. C is a mish-mash, not well structured, but quite capable of
getting "close to the metal". That is why Stroustrup came up with C++, to
organize and structure it. I can remember the Pascal bigots spitting at the
mention of C.

But, in any case, those are all _programming languages_, whatever their
individual merit. Access is not, it is a database development tool, which
shares a programming language with lots of other software -- that language
is suitable for its needs and addresses particularly well the needs of the
non-professional developer audience.

You think _David_ is a Microsoft-paid troll? Bwwaaahhahahahaha. Not only are
you a narrow-minded language bigot, you are almost as offbase as the
resident troll who targets him on other issues.

I don't know how long you've been in the computer business, Bernd, but I've
been in it since 1958, programming machines of all sizes, using a string of
languages longer than the average arm, at all different stages of language
development and maturity... I've bitswitched programs into a console and I
have dragged and dropped icons to create an application, and just about
everything in between. And, with those credentials, I say:

Access is an outstanding database development tool for a very wide range of
uses... from end-user data storage and manipulation all the way to client
applications for server databases, with some web-based capabilities as well.
It's not for writing operating systems, nor compilers, but the "normal
business database applications" for which it is suitable outnumber those by
the tens of thousands to one.

If you don't like it because it's not your favorite compiler, just give the
criticism a rest. The languages you like have their place, too -- but that
place is not "everywhere".

Larry Linson
Microsoft Access MVP
(FYI, that's not a paid position, and I am not a
Microsoft employee or contractor; it's a recognition
by Microsoft of people who've made a contribution
to the user community)

Nov 13 '05 #69

On Tue, 15 Jun 2004 22:10:41 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:tm********************************@4ax.com :
There is no excuse to ever write code without
Option Explicit, and it's the default setting to not have it.

Wasn't this changed back in A2K2 or A2K3 to default to having it on?

Or was that just including the DAO reference along with the useless
ADO reference?

The latter. You still have to turn on Require Variable declaration once on
each system, though the setting is remembered at the application level.

Nov 13 '05 #70

In message <ca*************@news.t-online.com>, Bernd Bollman
<be***@hotmail.com> writes

Bernard Peek wrote:
In message <ca*************@news.t-online.com>, Bernd Bollman
<be***@hotmail.com> writes
>David W. Fenton wrote:
>> Bernd Bollman <be***@hotmail.com> wrote:
>> > [...Microsoft Access...] For a new user
>> > with prior experience in other better designed systems it appears
>> > completely nonsensical.
>>
>> Please name some better-designed systems
>
>C, C++, Java and lots more.

None of the three languages you list would be suitable as a replacement
for VBA in Access

And I did not claim they are. The discussion is just about good vs.
bad design of programming environments.

No, it's not and it never has been. It's about good development
environments, which is not the same thing.

--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author. Will work for money.

Nov 13 '05 #71

In message <ca*************@news.t-online.com>, Bernd Bollman
<be***@hotmail.com> writes

Bernard Peek wrote:
I don't think Bernd is an idiot but I do think he is seriously mistaken
if he believes that any of those languages would be an improvement over
VBA within Access.

I dont believe this. I was merely stating my opinion about it without
providing a better alternative.
I agree with you here. I have no idea why anyone would attempt to learn
Access by reading the manual. No real users is likely (cue chorus of "We
did!") to start out that way. If they have enough experience with
Windows programs they will just start working through the menus,

But some day you may want or need to hack the code and therefore need
to learn the programming language.

Of course, eventually. But when you need to do that you can look at a
finished demo application and look at the code behind it. Then you can
cut and paste. You only need to understand a small fragment of code, not
the whole language. Programming is definitely one of the advanced
features of Access and most people don't start to use it until they are
already proficient with the basics. It's a mistake to approach Access
with the assumption that it's a programming environment.
--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author. Will work for money.

Nov 13 '05 #72

Larry Linson wrote:

"Bernd Bollman" wrote
> David W. Fenton wrote:
> > Well, I *am* an Access programmer, and
> > I have yet to see a serious critique of Access
> > from a language standpoint >
> That saying after you read and replied to my
> extensive explanations? Excuse me but I slowly
> start to think that you are a MS-paid troll.

"Extensive explanations"? You lost your credibility when you included C in
that list.

Aaahh, now we come to the point where ones credibility is completely
denied because of this and that opinion...
C is a mish-mash, not well structured,
It doesnt have the structuring techniques of OO languages but what it
provides is completely consistent. There are simply *no* ambiguities.
Thats why I consider it a cleaner, "nicer" design than e.g. VBA.
but quite capable of
getting "close to the metal". That is why Stroustrup came up with C++, to
organize and structure it.
Its a common misunderstanding to think that C++ is the successor to or
a "better" C. Its a completely new programming language with a very
different way of approaching a problem. I wonder why Stroustrup
decided to retain C as a subset if it is that bad...
I can remember the Pascal bigots spitting at the
mention of C.

But, in any case, those are all _programming languages_, whatever their
individual merit. Access is not, it is a database development tool, which
shares a programming language
And this language was the topic. It can be compared to other languages
independently from the rest of Access.
with lots of other software -- that language
is suitable for its needs and addresses particularly well the needs of the
non-professional developer audience.
I totally agree here! My point is just that while it perfectly meets
the needs for its application, I find it an ugly thing.
You think _David_ is a Microsoft-paid troll?
Not quite yet. But Im beginning to think it. I stated my dislike, he
asked why, I said why, he asked for specific technical reasons, I
provided them, he completely ignores them and still claims "he has
yet to see a serious critique of Access".
I don't know how long you've been in the computer business, Bernd, but I've
been in it since 1958, programming machines of all sizes, using a string of
languages longer than the average arm, at all different stages of language
development and maturity... I've bitswitched programs into a console and I
have dragged and dropped icons to create an application, and just about
everything in between. And, with those credentials, I say:

Access is an outstanding database development tool for a very wide range of
uses... from end-user data storage and manipulation all the way to client
applications for server databases, with some web-based capabilities as well.
It's not for writing operating systems, nor compilers, but the "normal
business database applications" for which it is suitable outnumber those by
the tens of thousands to one.
Ill say it one more and hopefully the last time: I dont think that there
are better alternatives to Access, Im not doubting its usefulness and
appropriateness for its problem area. I just think that its inner design
including the programming language VBA is very ugly and far from nice.
But Im *not* saying C or C++ or something else should be used instead.
If you don't like it because it's not your favorite compiler, just give the
criticism a rest. The languages you like have their place, too -- but that
place is not "everywhere".

I absolutely agree.

cheers, Bernd

Nov 13 '05 #73

Doug Hutcheson

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.74...
<snip>

Please name some better-designed systems that are the same kinds of
tools:

1. include a native, easy-to-use database engine, no extra
installation required.

2. include a flexible forms designer with a rich event model.

3. include a graphical query designer that allows you to write SQL
pretty easily without actually needing to know SQL.

4. include the best report designer, bar none, ever written.

5. include a scripting language to pull everything together.

6. include wizards to allow non-experts access to many of these
features without needing to fully understand them.

7. can be used as a fronte end to any back-end database engine that
provides an ODBC or ADO driver.

8. integrate with any other programs that offer the appropriate
interfaces.

9. easily support multiple users.

<huge snip>

David,
Well put.
I am a great supporter of Open Source / Linux, for a number of reasons.
However, I am also reasonably competent in MS Acess.

My biggest beef is that I cannot develop a DB app - complete with reports -
using Open Source as efficiently (read: cheaply/quickly) as I can using MS
Access with that wonderful reporting tool. Sigh.

And here is the bottom line: I am in business. For all my 25 years of
experience in Unix, C, blah blah...where do I make most of my money at the
small end of the market? Developing / supporting MS Access apps. It is not
my choice or even my preference, but I am not going to turn down a contract
to write VBA just because I have some religious fervour for Open Source.

Now, if someone clones the report writer, I will be keen to hear about
it...<grin>

Just my $0.02,
Doug
--
Remove the blots from my address to reply

Nov 13 '05 #74

Bernd Bollman <be***@hotmail.com> wrote in
news:ca*************@news.t-online.com:

Bernard Peek wrote:
In message <ca*************@news.t-online.com>, Bernd Bollman
<be***@hotmail.com> writes
>David W. Fenton wrote:
>> Bernd Bollman <be***@hotmail.com> wrote:
>> > [...Microsoft Access...] For a new user
>> > with prior experience in other better designed systems it
>> > appears completely nonsensical.
>>
>> Please name some better-designed systems
>
>C, C++, Java and lots more.

None of the three languages you list would be suitable as a
replacement for VBA in Access

And I did not claim they are. The discussion is just about good
vs. bad design of programming environments.

And that can only be evaluated in terms of suitability to task.

In regards to the task VBA is implemented in Access to perform, what
is wrong with the design of VBA?

The issue of OPTION EXPLICIT is really a red herring. This has to do
with different modalities that the language itself can be used in,
and, as someone else pointed out, there are plenty of languages out
there that don't require explicit variable definition *by design*,
and, indeed, that don't even *allow* for requiring it. Being someone
who believes in strong typing of variables, I would be very upset
with VBA if it did not allow you to use it with variable declaration
required because I've used languages that don't and know what kinds
of problems this creates.

I don't see the documentation as problematic, as the Access
documentation is not designed to teach you how to program in VBA,
but is designed to help you create database applications in Access.
VBA is one of the tools, so all of the documentation for VBA is
directed towards that end, and is specific to that context.

I see no valid significant criticism of VBA in anything you've
enumerated.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #75

Bernd Bollman <be***@hotmail.com> wrote in
news:ca*************@news.t-online.com:

David W. Fenton wrote:
Well, I *am* an Access programmer, and I have yet to see a
serious critique of Access from a language standpoint
That saying after you read and replied to my extensive
explanations? Excuse me but I slowly start to think that you are a
MS-paid troll.

Heh. Larry's already demolished the MS-paid remark, but I want to
re-iterate that you haven't provided any substantive criticism of
Access or VBA from a programmer's perspective in the abstract.
You've only cited your own issues with it, and those seem to me to
be due to your perspective, which seems quite insular to me.

> I agree with you here. I have no idea why anyone would attempt
> to learn Access by reading the manual. . . .

It's not reading the manual that's the issue. It's starting with
trying to learn the programming language without having learned
how to use Access itself first.

What the hell!? VBA is an essential part of Access and it can be
studied isolated from supergenious complete-form-with-all-bells-
and-whistles-creating Wizards and the like.

But you can't evaluate the implementation of VBA in Access without
looking at its context.

For instance, why the OPTION EXPLICIT statement as an optional
feature?

A. Because VBA is implemented across a family of applications, each
with different audiences, and Word and Excel are set up to not
require explicit variable declaration, presumably to make it easier
for novice macro writers to write code in Word and Excel.

In Access, I would definitely say that omitting OPTION EXPLICIT in
code would be a really bad decision, and MS's decision to make newly
created Access modules default to the same defaults as in Word and
Excel was a completely wrong-headed decision.

But the very structure of the language allows you require variable
declaration, and it also allows you to set your default for modules
to include OPTION EXPLICIT.

If I were to use your type of argument to criticize a gun I'd say
"My god! What a badly designed tool! You could put it to your head
and pull the trigger and kill yourself!"

Yes, you can shoot yourself in the foot with VBA, too,
metaphorically speaking.

You can also do that quite easily in the languages you mentioned
(indeed, more easily). That doesn't mean those languages are poorly
designed just because you can use them in bad ways.

Neither does the fact that variable declaration can be optional in
VBA make it badly designed.

Second, part of the power of Access is that it uses a language that
exists outside of itself, rather than having its own custom
scripting language. This means that Access's programming language
will therefore inherit all the baggage and history that comes with
that language.

C or C++ would be ridiculous languages for bundling into Access, as
they aren't high-level enough. Java would be reasonable, but still
pretty far from the way VB works with forms. But at the time Access
was created, Java was not an option, since in 1991-92, Java did not
exist outside of Sun (it was not even called Java yet).

What other languages existed in 1991-92 that were at that time
better structured than VB at that time, and also appropriate to a
database application development tool that was intended primarily
for end users, but also for knowledgable programmers?

There were no options.

VB was at that time the only language that made any sense
whatsoever.
I give up...

You haven't even begun to try.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #76

Tim Mills-Groninger

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.78...

Bernd Bollman <be***@hotmail.com> wrote in
news:ca*************@news.t-online.com:
David W. Fenton wrote:
Well, I *am* an Access programmer, and I have yet to see a
serious critique of Access from a language standpoint

That saying after you read and replied to my extensive
explanations? Excuse me but I slowly start to think that you are a
MS-paid troll.

And what's wrong with being a troll?

At least writing Access code give us something better to do than bother
folks walking on our bridges.

Tim Mills-Groninger

Nov 13 '05 #77

David W. Fenton wrote:

Bernd Bollman <be***@hotmail.com> wrote:
Bernard Peek wrote:
Bernd Bollman writes:
>David W. Fenton wrote:
>> Bernd Bollman <be***@hotmail.com> wrote:
>> > [...Microsoft Access...] For a new user
>> > with prior experience in other better designed systems it
>> > appears completely nonsensical.
>>
>> Please name some better-designed systems
>
>C, C++, Java and lots more.

None of the three languages you list would be suitable as a
replacement for VBA in Access
And I did not claim they are. The discussion is just about good
vs. bad design of programming environments.

And that can only be evaluated in terms of suitability to task.

In regards to the task VBA is implemented in Access to perform, what
is wrong with the design of VBA?

What does the application area of a programming language have to do
with variable declaration, assigning values, calling functions etc.?
The issue of OPTION EXPLICIT is really a red herring. This has to do
with different modalities that the language itself can be used in,
and, as someone else pointed out, there are plenty of languages out
there that don't require explicit variable definition *by design*,
and, indeed, that don't even *allow* for requiring it.
No problem with that. As long as they are consistent and dont provide
variable declaration at all, that can be considered a design decision
that has been made (allthough a poor one IMO). Unlike VBA where the
"designers" could not or did not want to or simply forgot to make a
decision and let the programmer decide which one of the dialects of
VBA he/she wants to use today. This is irritating at best and can
result in massive amounts of extra work to do, for example when you
want to reuse some existing code.
I don't see the documentation as problematic, as the Access
documentation is not designed to teach you how to program in VBA,
but is designed to help you create database applications in Access.
I repeat allthough it seems to be a waste of time in your case:
programming in VBA is an integral part of development with Access,
so the documentation should teach you that too.
VBA is one of the tools, so all of the documentation for VBA is
directed towards that end, and is specific to that context.
As stated above the fundamental language elements are not related
to the application area. And even if they were (e.g. as in LISP
which is primarily intended for manipulating lists) VBA's are still
inconsistent.
I see no valid significant criticism of VBA in anything you've
enumerated.

Now you finally have a *real* argument: you simply deny all of my
arguments. Is it really soo hard to admit that your beloved Access
has some problems? You seem to be a quite knowledgable guy and as
such you should be able to differentiate and know both the strengths
and weaknesses of your tools.

cheers, Bernd (disappointed)

Nov 13 '05 #78

David W. Fenton wrote:

Bernd Bollman <be***@hotmail.com> wrote:
David W. Fenton wrote:
Well, I *am* an Access programmer, and I have yet to see a
serious critique of Access from a language standpoint
That saying after you read and replied to my extensive
explanations? Excuse me but I slowly start to think that you are a
MS-paid troll.

Heh. Larry's already demolished the MS-paid remark, but I want to
re-iterate that you haven't provided any substantive criticism of
Access or VBA from a programmer's perspective in the abstract.

Yes I have. You just ignore them.
You've only cited your own issues with it, and those seem to me to
be due to your perspective, which seems quite insular to me.
Ok, so we have a very very different view about what makes a good
or bad design. Im glad I dont have to rely on applications that were
written by someone with such an attitude towards software development.

> I agree with you here. I have no idea why anyone would attempt
> to learn Access by reading the manual. . . .

It's not reading the manual that's the issue. It's starting with
trying to learn the programming language without having learned
how to use Access itself first.

What the hell!? VBA is an essential part of Access and it can be
studied isolated from supergenious complete-form-with-all-bells-
and-whistles-creating Wizards and the like.

But you can't evaluate the implementation of VBA in Access without
looking at its context.

When looking at variable declaration whats the difference if this
variable is used to hold some record count, a control element or a
line of text?
For instance, why the OPTION EXPLICIT statement as an optional
feature?
[...]
I dont care whats the reason for having it. Its just a horrible
misfeature.
If I were to use your type of argument to criticize a gun I'd say
"My god! What a badly designed tool! You could put it to your head
and pull the trigger and kill yourself!"

Yes, you can shoot yourself in the foot with VBA, too,
metaphorically speaking.
Yes you can do that in any language.
You can also do that quite easily in the languages you mentioned
(indeed, more easily). That doesn't mean those languages are poorly
designed just because you can use them in bad ways.
Correct. But I know of no other language that allows to invalidate
huge amounts of code by a single switch. And I dont see a single
reason for having it (besides saving some typing).
Neither does the fact that variable declaration can be optional in
VBA make it badly designed.

This seems to be a matter of personal taste in which we deeply
disagree.

cheers, Bernd

Nov 13 '05 #79

In message <cb*************@news.t-online.com>, Bernd Bollman
<be***@hotmail.com> writes

David W. Fenton wrote:
Bernd Bollman <be***@hotmail.com> wrote:
> Bernard Peek wrote:
>> Bernd Bollman writes:
>> >David W. Fenton wrote:
>> >> Bernd Bollman <be***@hotmail.com> wrote:
>> >> > [...Microsoft Access...] For a new user
>> >> > with prior experience in other better designed systems it
>> >> > appears completely nonsensical.
>> >>
>> >> Please name some better-designed systems
>> >
>> >C, C++, Java and lots more.
>>
>> None of the three languages you list would be suitable as a
>> replacement for VBA in Access
>
> And I did not claim they are. The discussion is just about good
> vs. bad design of programming environments.
And that can only be evaluated in terms of suitability to task.

In regards to the task VBA is implemented in Access to perform, what
is wrong with the design of VBA?

What does the application area of a programming language have to do
with variable declaration, assigning values, calling functions etc.?

The application area decides which people will want to use the language.
In the case of VBA the majority of users are not professional
programmers, they write code only when forced to.

[...]

I don't see the documentation as problematic, as the Access
documentation is not designed to teach you how to program in VBA,
but is designed to help you create database applications in Access.
I repeat allthough it seems to be a waste of time in your case:
programming in VBA is an integral part of development with Access,
so the documentation should teach you that too.

And we keep correcting you on this. Programming is not even an essential
part of developing applications with Access. I think that more than half
of the people developing applications in Access use VBA, but it wouldn't
surprise me to find out that it was less. I'm sure the majority of
Access users don't do any development at all, they use applications
designed by others.

I repeat, Access is an application development system, not a program
development system.

If you want documentation to teach you how to program in VBA you can get
it from any large bookstore. I can see good reasons why the
documentation is sold separately. A relatively small number of people
require it (compared with the number of users who have Access licenses)
and providing the necessary documentation would be expensive. There's
also the fact that it's easy to copy the Access software and use a
pirate version, less easy to pirate a 1000 page textbook. That's the
same copy-protection systems used in Turbo Pascal 3 when I first used
it.

VBA is one of the tools, so all of the documentation for VBA is
directed towards that end, and is specific to that context.

As stated above the fundamental language elements are not related
to the application area. And even if they were (e.g. as in LISP
which is primarily intended for manipulating lists) VBA's are still
inconsistent.
I see no valid significant criticism of VBA in anything you've
enumerated.

Now you finally have a *real* argument: you simply deny all of my
arguments. Is it really soo hard to admit that your beloved Access
has some problems? You seem to be a quite knowledgable guy and as
such you should be able to differentiate and know both the strengths
and weaknesses of your tools.

I don't think that anyone is disputing the fact that Access is
imperfect, but you haven't yet come up with any suggestions that would
be likely to improve it. Even your suggestion to retain OPTION EXPLICIT
as a default (which everyone here seems to agree on) would break
backward compatibility and existing code for some developers.

--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author. Will work for money.

Nov 13 '05 #80

Bernd Bollman <be***@hotmail.com> wrote in
news:cb*************@news.t-online.com:

David W. Fenton wrote:
Bernd Bollman <be***@hotmail.com> wrote:
> Bernard Peek wrote:
>> Bernd Bollman writes:
>> >David W. Fenton wrote:
>> >> Bernd Bollman <be***@hotmail.com> wrote:
>> >> > [...Microsoft Access...] For a new user
>> >> > with prior experience in other better designed systems it
>> >> > appears completely nonsensical.
>> >>
>> >> Please name some better-designed systems
>> >
>> >C, C++, Java and lots more.
>>
>> None of the three languages you list would be suitable as a
>> replacement for VBA in Access
>
> And I did not claim they are. The discussion is just about good
> vs. bad design of programming environments.
And that can only be evaluated in terms of suitability to task.

In regards to the task VBA is implemented in Access to perform,
what is wrong with the design of VBA?

What does the application area of a programming language have to
do with variable declaration, assigning values, calling functions
etc.?

???

It has *everything* to do with it.

The design of a language should reflect the purpose for which it is
to be used. VBA's does that. There is no real abstract basis for
criticising the way VBA allows you to turn required variable
declaration on or off.

The issue of OPTION EXPLICIT is really a red herring. This has to
do with different modalities that the language itself can be used
in, and, as someone else pointed out, there are plenty of
languages out there that don't require explicit variable
definition *by design*, and, indeed, that don't even *allow* for
requiring it.

No problem with that. As long as they are consistent and dont
provide variable declaration at all, that can be considered a
design decision that has been made (allthough a poor one IMO).
Unlike VBA where the "designers" could not or did not want to or
simply forgot to make a decision and let the programmer decide
which one of the dialects of VBA he/she wants to use today. This
is irritating at best and can result in massive amounts of extra
work to do, for example when you want to reuse some existing code.

I could make the same criticism of C or C++ in regard to memory
management.

It is simply not an issue for anyone who works regularly in Access
-- you either have OPTION EXPLICIT turned on by default or you
don't. Each module can be independent, and if you are inconsistent
in how you use it, then if you're not doing it for a reason, you are
a sloppy programmer. I don't really think the language should be
designed to prevent you from being a sloppy programmer, since one
man's sloppy is another's flexible.

I don't see the documentation as problematic, as the Access
documentation is not designed to teach you how to program in VBA,
but is designed to help you create database applications in
Access.

I repeat allthough it seems to be a waste of time in your case:
programming in VBA is an integral part of development with Access,
so the documentation should teach you that too.

You can develop applications in Access without writing a single line
of code yourself.

So, while VBA may be "integral" to Access development, I can't see
that knowledge and documentation of VBA per se is necessary to be
able to use the tool.

And, in fact, there's tons of documentation of VBA in the help
files, but it's conveyed in relation to application development
tasks, rather than as a standalone abstract programming course. In
short, the help files are designed to help you use Access, and
instruction in how to use VBA is secondary to that.

You seem to think it's a deficiency that there is no real dedicated
VBA-from-start-to-finish documentation. That kind of documentation
would be useless, because of the way VBA is integrated into Access.

VBA is one of the tools, so all of the documentation for VBA is
directed towards that end, and is specific to that context.

As stated above the fundamental language elements are not related
to the application area. And even if they were (e.g. as in LISP
which is primarily intended for manipulating lists) VBA's are
still inconsistent.

And why is inconsistency a problem? As I said above, one man's
inconsistency is another man's flexibility.

I see no valid significant criticism of VBA in anything you've
enumerated.

Now you finally have a *real* argument: you simply deny all of my
arguments. Is it really soo hard to admit that your beloved Access
has some problems? . . .

I am one of the harshest critics of Access in this newsgroup. I know
it's flaws far, far better than you ever will from your cursory
examination of the VBA documentation because I have been programming
in it practically every day for the last 8 years.
. . . You seem to be a quite knowledgable guy and as
such you should be able to differentiate and know both the
strengths and weaknesses of your tools.

I do know the strengths and weaknesses.

And they aren't what you think they are.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #81

Bernard Peek <ba*@shrdlu.com> wrote in
news:38**************@shrdlu.com:

Programming is not even an essential
part of developing applications with Access. I think that more
than half of the people developing applications in Access use VBA,
but it wouldn't surprise me to find out that it was less. I'm sure
the majority of Access users don't do any development at all, they
use applications designed by others.

None of the last three applications that I've been hired to fix that
were originally developed by "professional" programmers included not
one single line of code that had not been generated by a wizard.

That is, there are lots of people making their living developing
Access applications who know nothing whatsoever about VBA.

And I think that's testimony to how remarkable a product Access
happens to be.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #82

Bernd Bollman <be***@hotmail.com> wrote in
news:cb*************@news.t-online.com:

David W. Fenton wrote:

The issue of OPTION EXPLICIT is really a red herring. This has to
do with different modalities that the language itself can be used
in, and, as someone else pointed out, there are plenty of
languages out there that don't require explicit variable
definition *by design*, and, indeed, that don't even *allow* for
requiring it.

No problem with that. As long as they are consistent and dont
provide variable declaration at all, that can be considered a
design decision that has been made (allthough a poor one IMO).
Unlike VBA where the "designers" could not or did not want to or
simply forgot to make a decision and let the programmer decide
which one of the dialects of VBA he/she wants to use today. This
is irritating at best and can result in massive amounts of extra
work to do, for example when you want to reuse some existing code.

You're obviously misinformed. The programmer does *not* have to
which "decide one of the dialects of VBA he/she wants to use today."
That is, this is not a choice one has to make each time one creates
a new code module.

Instead, Access has a setting that controls the default settings for
newly created modules. In A97 and before, OPTION EXPLICIT was by
default inserted into every module at creation (though you could set
it to *not* be). Starting with A2K, in order to make Access modules
consistent with those in Word and Excel (a stupid goal, in my
opinion), the default setting was that new modules were created
*without* OPTION EXPLICIT.

But the first time every experienced programmer ran A2K, she went to
the VBE options and changed it so that OPTION EXPLICIT was inserted
in every newly created module.

So, it's a decision you make ONE TIME, and then every new module
inherits properties based on that decision.

Looking at the VBA documentation apprently gave you an entirely
erroneous impression about how code is written in Access.

In short, your criticism in this instance is completely groundless
and reflects your ignorance about how Access actually works.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #83

Bernd Bollman <be***@hotmail.com> wrote in
news:cb*************@news.t-online.com:

David W. Fenton wrote:
Bernd Bollman <be***@hotmail.com> wrote:
> David W. Fenton wrote:
>> Well, I *am* an Access programmer, and I have yet to see a
>> serious critique of Access from a language standpoint
>
> That saying after you read and replied to my extensive
> explanations? Excuse me but I slowly start to think that you
> are a MS-paid troll.

Heh. Larry's already demolished the MS-paid remark, but I want to
re-iterate that you haven't provided any substantive criticism of
Access or VBA from a programmer's perspective in the abstract.

Yes I have. You just ignore them.

No, I haven't ignored them. I've demonstrated why your criticisms
simply miss the point.

[]

Neither does the fact that variable declaration can be optional
in VBA make it badly designed.

This seems to be a matter of personal taste in which we deeply
disagree.

Well, I've been saying all along that there I've seen no substantive
criticism of VBA that does not come down to personal taste.

At least we are in agreement on that.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #84

James Fortune

st***@nospam.com (Steve) wrote in message news:<40***************@news.westnet.com>...

But it is so easy to check the default "require variable declarations"
option on.

I agree with your defense of Access. So much complaining about
Access; but very few products that can really compete with it for
database centric RAD applications.

Steven

Having programmed in nearly all the languages and OS's mentioned in
this thread (except COBOL and Lisp), here are a few comments/ramblings
I have:

Bill Gates' idea, perhaps driven in part by nostalgia, of gentrifying
BASIC into a full programming language was very important. The main
programming languages at that time fit into the Basic/Fortran,
Pascal/Ada and C/C++ styles. The C/C++ languages and even the
Pascal/Ada languages required special purpose I/O routines for simple
tasks. The additions to BASIC that became VB allowed it to be
programmed in a structured way. VB's simplicity allowed developers to
create robust applications quickly yet still allowed for C/C++ or
assembly code extensions when extra speed was required.

I had already created some applications using VB 3.0 and VC++ 1.0 when
Paradox database programming using PAL was getting popular. Database
programming using PAL was a lot easier than creating data structures
and methods for accessing that data. The most frustrating part about
PAL, possibly because of my lack of experience, was getting the syntax
correct. Access 2.0 looked amazingly like Paradox except that the
built-in tools helped me get the syntax down quicker. I already knew
enough VB to do the rest. I felt sorry for Borland that MS blew the
original innovator out of the water, but I knew that to ignore MS
software would be a backward step professionally. I made the decision
that no matter what other OS's and languages I learned that I would be
able to do it using Windows and MS products also. VBA has been the
key to keeping clients happy rather than frustrating them. VBA is not
perfect, but if development time is inversely proportional to
perfection then VBA is the closest to perfection. Being able to
integrate with MS Office products using Automation is a bonus.

Some weaknesses of VBA when used with Access:
- There should be thousands of ActiveX controls by now.
- Having to stop subform code for other tasks from running when it
gets focus
- Keeping track of where you are on a Subform including field and
cursor position is a major hassle
- All the arcana that can getcha (Unicode, Jet behavior, bad indices,
etc.)
- Speed/Variable Declaration tradeoffs encourage large subroutines

Conclusion: For me, Access won't face any serious competition for some
time.

James A. Fortune

Nov 13 '05 #85

On 21 Jun 2004 01:14:18 -0700, ja******@oakland.edu (James Fortune) wrote:

st***@nospam.com (Steve) wrote in message news:<40***************@news.westnet.com>...
But it is so easy to check the default "require variable declarations"
option on.

I agree with your defense of Access. So much complaining about
Access; but very few products that can really compete with it for
database centric RAD applications.

Steven
Having programmed in nearly all the languages and OS's mentioned in
this thread (except COBOL and Lisp), here are a few comments/ramblings
I have:

Bill Gates' idea, perhaps driven in part by nostalgia, of gentrifying
BASIC into a full programming language was very important. The main

Well, it was Microsoft's idea. Whether it was Bill's or not, we'll probably
never know.
programming languages at that time fit into the Basic/Fortran,
Pascal/Ada and C/C++ styles. The C/C++ languages and even the
Pascal/Ada languages required special purpose I/O routines for simple
tasks. The additions to BASIC that became VB allowed it to be
programmed in a structured way. VB's simplicity allowed developers to
create robust applications quickly yet still allowed for C/C++ or
assembly code extensions when extra speed was required.

I had already created some applications using VB 3.0 and VC++ 1.0 when
Paradox database programming using PAL was getting popular. Database
programming using PAL was a lot easier than creating data structures
and methods for accessing that data. The most frustrating part about
PAL, possibly because of my lack of experience, was getting the syntax
correct. Access 2.0 looked amazingly like Paradox except that the
built-in tools helped me get the syntax down quicker. I already knew
enough VB to do the rest. I felt sorry for Borland that MS blew the
original innovator out of the water, but I knew that to ignore MS
software would be a backward step professionally. I made the decision
that no matter what other OS's and languages I learned that I would be
able to do it using Windows and MS products also. VBA has been the
key to keeping clients happy rather than frustrating them. VBA is not
perfect, but if development time is inversely proportional to
perfection then VBA is the closest to perfection. Being able to
integrate with MS Office products using Automation is a bonus.
Neither Paradox nor PAL ever did as much as Access even not counting the
auto-sense. Object PAL would have been a step in the right direction if it
wasn't so buggy and visually gaudy. FoxPro was great. It wasn't as much of a
user database as Access, but it had a better event model than Access has now,
and its biggest benefit was that it was the only database front-end in its
class that ran on something other than Windows (Macintosh).

I used to support Windows and Mac in FoxPro until Microsoft bought it out and
discontinued macintosh support. Now, they're supporting Macs for all of MS
Office except Access, so there's still nothing decent on anything but Windows.

Some weaknesses of VBA when used with Access:
- There should be thousands of ActiveX controls by now.
Ack - no. The reason there are not that many ActiveX controls is that each
ActiveX control adds complexity to deployment, so most of us use only the
barest minimum ActiveX controls we can get away with. It sould be nice if
there was a way to implement controls with the same flexibility directly in
VBA, but there isn't.
- Having to stop subform code for other tasks from running when it
gets focus
I'm not sure what you mean, so I might or might not agree. Can you be more
specific? There certainly are issues with interaction between form and
subform code.
- Keeping track of where you are on a Subform including field and
cursor position is a major hassle
You mean making it visually obvious when the focus is not on the subform?
It's a hassle, but not too major if you know how the trick. I'll provide more
details if you want.
- All the arcana that can getcha (Unicode, Jet behavior, bad indices,
etc.)
And numeric fields defaulting to have a default value of zero, text fields
defaulting to allow both nulls and blank strings, Name Autocorrect being on by
default and corrupting your code, ...
- Speed/Variable Declaration tradeoffs encourage large subroutines
This is never an issue for me. The database file operations are generally the
bottleneck in my apps, so I don't need to worry about micro-optimizing my
code. Now, error handling is another matter. I've factored the majority of
my error handler into a class module, but there's still a variable declaration
and a minimum of about 6 lines of error handling block at the end of pretty
much every procedure to get good error info for the developer, and the blocks
are mostly all identical except for the hard-coded procedure name.
Conclusion: For me, Access won't face any serious competition for some
time.
Well, I agree it -probably won't. It doesn't have any serious competition
now, but I'm not sure why that couldn't change rapidly if someone came along
with the will and a solid, simple design idea that covered most of the bases.

James A. Fortune

Nov 13 '05 #86

Bernard Peek wrote:

What does the application area of a programming language have to do
with variable declaration, assigning values, calling functions etc.?
The application area decides which people will want to use the language.
In the case of VBA the majority of users are not professional
programmers, they write code only when forced to.

But that doesnt void the fact that VBA is inconsistent even at the
lowest level.

I repeat allthough it seems to be a waste of time in your case:
programming in VBA is an integral part of development with Access,
so the documentation should teach you that too.

And we keep correcting you on this. Programming is not even an essential
part of developing applications with Access. I think that more than half
of the people developing applications in Access use VBA, but it wouldn't
surprise me to find out that it was less. I'm sure the majority of
Access users don't do any development at all, they use applications
designed by others.

Well, I wouldnt have come very far without writing VBA when I once
had to work with Access (*shudder* that were hard times). Furthermore
I could give you countless examples of other things besides VBA in
Access that are ugly and senseless (but I won't, please dont ask for
it). But VBA and it's docs still suck regardless of how many of the
Access users actually use it.
If you want documentation to teach you how to program in VBA you can get
it from any large bookstore. I can see good reasons why the
documentation is sold separately. A relatively small number of people
require it (compared with the number of users who have Access licenses)
and providing the necessary documentation would be expensive.
So you agree that the Access documentation sucks. Very well :)
I don't think that anyone is disputing the fact that Access is
imperfect,
Mr. Fenton is. But I gave up arguing with him.
but you haven't yet come up with any suggestions that would
be likely to improve it.
I did not intend to provide suggestions for improvement. But here
are some: Remove one of "Dim" or "Private", make variable declaration
mandatory or remove it altogether (in the former case also get rid
of type "Variant"), in the docs sort by topics instead of
alphabetically and generally clean it up (bogus topic names).
Even your suggestion to retain OPTION EXPLICIT
as a default (which everyone here seems to agree on) would break
backward compatibility and existing code for some developers.

He he, that one is really funny. You as users of Microsoft products
should by now have grown accustomed to regularly losing backward
compatibility. But better some hassle now than endless pains.

On the other hand it would not hurt anybody anyway because, as
you told me, almost noone uses VBA ;)

cheers, Bernd

Nov 13 '05 #87

In message <cb*************@news.t-online.com>, Bernd Bollman
<be***@hotmail.com> writes

Bernard Peek wrote:
>What does the application area of a programming language have to do
>with variable declaration, assigning values, calling functions etc.?
The application area decides which people will want to use the language.
In the case of VBA the majority of users are not professional
programmers, they write code only when forced to.

But that doesnt void the fact that VBA is inconsistent even at the
lowest level.

True. It's not a perfect language and I'm not trying to pretend that it
is. Given its history it's not at all surprising that it is full of
kludges. Each iteration has moved it closer to what we might think of as
a fully developed programming language. I now think that it has moved
too far in that direction.

>I repeat allthough it seems to be a waste of time in your case:
>programming in VBA is an integral part of development with Access,
>so the documentation should teach you that too.
And we keep correcting you on this. Programming is not even an essential
part of developing applications with Access. I think that more than half
of the people developing applications in Access use VBA, but it wouldn't
surprise me to find out that it was less. I'm sure the majority of
Access users don't do any development at all, they use applications
designed by others.

Well, I wouldnt have come very far without writing VBA when I once
had to work with Access (*shudder* that were hard times). Furthermore
I could give you countless examples of other things besides VBA in
Access that are ugly and senseless (but I won't, please dont ask for
it). But VBA and it's docs still suck regardless of how many of the
Access users actually use it.

I'm quite prepared to believe that from a programmer's point of view the
Access system, and VBA, sucks. That's why I keep emphasising that Access
is an application development system that is primarily aimed at people
who cannot or will not write programs.

If you want documentation to teach you how to program in VBA you can get
it from any large bookstore. I can see good reasons why the
documentation is sold separately. A relatively small number of people
require it (compared with the number of users who have Access licenses)
and providing the necessary documentation would be expensive.
So you agree that the Access documentation sucks. Very well :)

The documentation provided with Access sucks. That's not quite the same
as saying that Access documentation sucks. I have a shelf full of very
good documentation on Access, but I bought it separately from the
software.

I don't think that anyone is disputing the fact that Access is
imperfect,
Mr. Fenton is. But I gave up arguing with him.

I think you're being a little harsh, but then so is he.

He has said that Access is an excellent tool for the type of job that it
was designed for, and I agree with that. I have been looking for an
equivalent Linux program for several years. There are no free (as in
beer) equivalents that I have been able to find.

but you haven't yet come up with any suggestions that would
be likely to improve it.
I did not intend to provide suggestions for improvement. But here
are some: Remove one of "Dim" or "Private", make variable declaration
mandatory or remove it altogether (in the former case also get rid
of type "Variant"),

in the docs sort by topics instead of
alphabetically and generally clean it up (bogus topic names).
I can see how that would be useful, and also why Microsoft isn't going
to do it. They really don't want anyone to be able to learn Access from
the software. As so many people run pirate copies of the software
Microsoft is making less and less money from software sales and more and
more from selling books. If you want sufficient documentation to be able
to learn Access then Microsoft will be only too pleased to sell it to
you. There is quite a lot of additional material on Microsoft's web
site, some of it closer to what you are looking for.

If Microsoft's software activation system works in preventing pirate
software then we may see much more on-line documentation provided with
the software.

Even your suggestion to retain OPTION EXPLICIT
as a default (which everyone here seems to agree on) would break
backward compatibility and existing code for some developers.

He he, that one is really funny. You as users of Microsoft products
should by now have grown accustomed to regularly losing backward
compatibility. But better some hassle now than endless pains.

On the other hand it would not hurt anybody anyway because, as
you told me, almost noone uses VBA ;)

There are possibly as many people developing with VBA as there are of
every other programming language added together. But that is still only
a small fraction of Access users.

--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author. Will work for money.

Nov 13 '05 #88

Bernd Bollman <be***@hotmail.com> wrote in
news:cb*************@news.t-online.com:

Bernard Peek wrote:

[]

I don't think that anyone is disputing the fact that Access is
imperfect,

Mr. Fenton is. But I gave up arguing with him.

No, I've never suggested that Access is perfect.

I've only repeatedly explained why your examples of what is wrong
with VBA completely miss the point, and aren't really substantive
criticisms of Access or VBA.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #89

Bernd Bollman <be***@hotmail.com> wrote in
news:cb*************@news.t-online.com:

I did not intend to provide suggestions for improvement. But here
are some: Remove one of "Dim" or "Private", make variable
declaration mandatory or remove it altogether (in the former case
also get rid of type "Variant"), in the docs sort by topics
instead of alphabetically and generally clean it up (bogus topic
names).

If you think getting rid of the Variant data type would be a good
idea, then you really haven't a clue about what you're talking
about.

I think it would be good if VBA got rid of the lack of requirement
to declare the data type. That is, you can write:

Dim VariableName

and it will auto-type as variant. I think that's bad, because it
leads to bad code.

But it's there for consistency with the way VBA is used in
non-Access contexts. In a database context, I don't think there's
any justification for any implicit variable typing.

But getting rid of the variant data type would completely cripple
VBA for interacting with actual fields and records in data tables,
where a Null value is important and distince from a ZLS.

If you don't know why that is the case, then you haven't done much
database programming and demonstrate that you really aren't
qualified to be judging VBA's suitability to its use as scripting
language for a database development environment.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #90

Bernd Bollman <be***@hotmail.com> wrote in
news:cb*************@news.t-online.com:

Bernard Peek wrote:

[]

Even your suggestion to retain OPTION EXPLICIT
as a default (which everyone here seems to agree on) would break
backward compatibility and existing code for some developers.

He he, that one is really funny. You as users of Microsoft
products should by now have grown accustomed to regularly losing
backward compatibility. But better some hassle now than endless
pains.

Microsoft has done a better job with maintaining backward
compatibility than any other major software vendor still in
business.

http://weblogs.asp.net/Rick_Schaut/a.../26/80193.aspx
http://www.joelonsoftware.com/articles/APIWar.html

Joel Sposky argues that MS is screwing up in starting to depart from
their history of backward compatibility.

But given that I have clients running dBase II programs compiled in
1984 under Win2K and WinXP, and that every application I have
purchased in the last 15 years runs just fine (although occasionally
with some tweaks to registry security settings) on the current
versions of Windows, the idea that MS is a big offender in breaking
backward compatibility is ludicrous.

It's especially ludicrous in the context of Access.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #91

James Fortune

Steve Jorgensen <no****@nospam.nospam> wrote in message news:<b4********************************@4ax.com>. ..

On 21 Jun 2004 01:14:18 -0700, ja******@oakland.edu (James Fortune) wrote:
Some weaknesses of VBA when used with Access:
- There should be thousands of ActiveX controls by now.
Ack - no. The reason there are not that many ActiveX controls is that each
ActiveX control adds complexity to deployment, so most of us use only the
barest minimum ActiveX controls we can get away with. It sould be nice if
there was a way to implement controls with the same flexibility directly in
VBA, but there isn't.

Point taken. I meant controls built directly into Access that make
life easier.

- Having to stop subform code for other tasks from running when it
gets focus
I'm not sure what you mean, so I might or might not agree. Can you be more
specific? There certainly are issues with interaction between form and
subform code.

When I change the SourceObject of a subform, the subform automatically
tries to run the Enter Code of the first field. Since I am using the
Enter Code as part of a strategy to detect the last field visited I
have to put code in to bypass this event in cases such as when code is
being used to insert or delete records.

- Keeping track of where you are on a Subform including field and
cursor position is a major hassle

You mean making it visually obvious when the focus is not on the subform?
It's a hassle, but not too major if you know how the trick. I'll provide more
details if you want.

One of the reasons I need to keep track of where I am on a subform is
that when a user has overridden my pdf symbol description syntax and
made a mistake I want to take them to the spot on the subform where
the error occurred right to the exact character. Other situations I
have come across required knowledge of where the user was at on the
subform. I'd be interested in hearing about better ways of getting
back to a certain location on the subform.

- All the arcana that can getcha (Unicode, Jet behavior, bad indices,
etc.)

And numeric fields defaulting to have a default value of zero, text fields
defaulting to allow both nulls and blank strings, Name Autocorrect being on by
default and corrupting your code, ...

Yes.

- Speed/Variable Declaration tradeoffs encourage large subroutines

This is never an issue for me. The database file operations are generally the
bottleneck in my apps, so I don't need to worry about micro-optimizing my
code. Now, error handling is another matter. I've factored the majority of
my error handler into a class module, but there's still a variable declaration
and a minimum of about 6 lines of error handling block at the end of pretty
much every procedure to get good error info for the developer, and the blocks
are mostly all identical except for the hard-coded procedure name.

The problem is that these monolithic subroutines add complexity. They
can be managed but they are unruly beasts. They are only reusable in
a "cut-and-paste pieces" sense. In one case the most efficient way to
keep code repetition down was to use the old-fashioned GOSUB method
(yuck). Quite often natural places to create new subroutines require
moving many variables to form variables and passing recordsets. It's
not a serious problem but it is a weakness. Being able to break the
code down easily into smaller subroutines adds reliability.

Conclusion: For me, Access won't face any serious competition for some
time.

Well, I agree it -probably won't. It doesn't have any serious competition
now, but I'm not sure why that couldn't change rapidly if someone came along
with the will and a solid, simple design idea that covered most of the bases.

Getting such an OpenSource product up to speed would take a lot of
interaction with users. A new commercial product is more capable of
blindsiding Access.

James A. Fortune

Nov 13 '05 #92

David W. Fenton wrote:

Bernd Bollman <be***@hotmail.com> wrote in
He he, that one is really funny. You as users of Microsoft
products should by now have grown accustomed to regularly losing
backward compatibility. But better some hassle now than endless
pains.

Microsoft has done a better job with maintaining backward
compatibility than any other major software vendor still in
business.

Im sorry, I really messed that one up. What I meant was the backward
compatibility of MS' new technologies to the developers existing
knowledge (currently e.g. .Net requiring previous MFC programmers to
relearn everything from scratch). And this is based on Windows' lack
of a good design. Contrast this with Unix which has a beautiful and
powerful design. The defacto standard reference for Unix programming
is "Advanced Programming in the Unix Environment" by W. Richard
Stevens, a book from 1992! Many very old books even from the 70's
still provide useful information that holds true nearly unchanged.

cheers, Bernd

Nov 13 '05 #93

ja******@oakland.edu (James Fortune) wrote in
news:a6*************************@posting.google.co m:

Steve Jorgensen <no****@nospam.nospam> wrote in message
news:<b4********************************@4ax.com>. ..
>On 21 Jun 2004 01:14:18 -0700, ja******@oakland.edu (James
>Fortune) wrote:
[]
>- Having to stop subform code for other tasks from running when
>it gets focus
I'm not sure what you mean, so I might or might not agree. Can
you be more specific? There certainly are issues with
interaction between form and subform code.

When I change the SourceObject of a subform, the subform
automatically tries to run the Enter Code of the first field.
Since I am using the Enter Code as part of a strategy to detect
the last field visited I have to put code in to bypass this event
in cases such as when code is being used to insert or delete
records.

If the subform control is not enabled, the field can't get the focus
and fire an OnEnter event, no? Or if the field is disabled until you
want it to be, same thing.

>- Keeping track of where you are on a Subform including field
>and cursor position is a major hassle

You mean making it visually obvious when the focus is not on the
subform? It's a hassle, but not too major if you know how the
trick. I'll provide more details if you want.

One of the reasons I need to keep track of where I am on a subform
is that when a user has overridden my pdf symbol description
syntax and made a mistake I want to take them to the spot on the
subform where the error occurred right to the exact character.
Other situations I have come across required knowledge of where
the user was at on the subform. I'd be interested in hearing
about better ways of getting back to a certain location on the
subform.

This is why I put validation code in the BeforeUpdate events of the
individual fields, so problems can be intercepted as soon as they
are made and before the user is able to leave the field. It's easy
enough to write code that takes Screen.ActiveControl and tests the
validity of the data. That should be all you need, no?

[]

>- Speed/Variable Declaration tradeoffs encourage large
>subroutines

This is never an issue for me. The database file operations are
generally the bottleneck in my apps, so I don't need to worry
about micro-optimizing my code. Now, error handling is another
matter. I've factored the majority of my error handler into a
class module, but there's still a variable declaration and a
minimum of about 6 lines of error handling block at the end of
pretty much every procedure to get good error info for the
developer, and the blocks are mostly all identical except for the
hard-coded procedure name.

The problem is that these monolithic subroutines add complexity.

But Steve is saying there's no *need* for "monolithic subroutines"
by virtue of the performance problems you allege.
They can be managed but they are unruly beasts. They are only
reusable in a "cut-and-paste pieces" sense. In one case the most
efficient way to keep code repetition down was to use the
old-fashioned GOSUB method (yuck). Quite often natural places to
create new subroutines require moving many variables to form
variables and passing recordsets. It's not a serious problem but
it is a weakness. Being able to break the code down easily into
smaller subroutines adds reliability.

Or you could pass the relevant variables in the subroutines
parameters.

Or, if that becomes too complex and too many of the parameters are
optional, wrap the whole thing in a class module where you
initialize the instance of it, assign various properties to it that
are appropriate for the context and then execute whatever
appropriate method.

I often do this where I might have a dozen parameters that I'd be
passing to a subroutine, some arbitrary collection of which might be
optional.

>Conclusion: For me, Access won't face any serious competition
>for some time.

Well, I agree it -probably won't. It doesn't have any serious
competition now, but I'm not sure why that couldn't change
rapidly if someone came along with the will and a solid, simple
design idea that covered most of the bases.

Getting such an OpenSource product up to speed would take a lot of
interaction with users. A new commercial product is more capable
of blindsiding Access.

A development tool that left out the needs of the end users would
not bother me. If the RAD capabilities were as good as Access, I
wouldn't care if it didn't have any wizards and hand holding for
novices.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #94

Bernard Peek wrote:

I have been looking for an
equivalent Linux program for several years. There are no free (as in
beer) equivalents that I have been able to find.
I'll notify you should I happen to stumble across such a thing ;)
There is quite a lot of additional material on Microsoft's web
site, some of it closer to what you are looking for.

Good heavens! Im not looking for more :)

cheers, Bernd

Nov 13 '05 #95

Doug Hutcheson

"Bernd Bollman" <be***@hotmail.com> wrote in message
news:cb*************@news.t-online.com...

David W. Fenton wrote:
Bernd Bollman <be***@hotmail.com> wrote in
He he, that one is really funny. You as users of Microsoft
products should by now have grown accustomed to regularly losing
backward compatibility. But better some hassle now than endless
pains.

Microsoft has done a better job with maintaining backward
compatibility than any other major software vendor still in
business.

Im sorry, I really messed that one up. What I meant was the backward
compatibility of MS' new technologies to the developers existing
knowledge (currently e.g. .Net requiring previous MFC programmers to
relearn everything from scratch). And this is based on Windows' lack
of a good design. Contrast this with Unix which has a beautiful and
powerful design. The defacto standard reference for Unix programming
is "Advanced Programming in the Unix Environment" by W. Richard
Stevens, a book from 1992! Many very old books even from the 70's
still provide useful information that holds true nearly unchanged.

cheers, Bernd

Bernd,
Yep - relearning is the killer for me.

As an employee of VeryBigCompany.com, I would expect (demand?) to have
training handed to me on a plate, if my employer decided to upgrade to a
newer o/s or language version.

As an indpendent, I have severe constraints on both time and money available
for retooling my workbench and upskilling my brain, so I prefer to work with
things I know and trust or can afford to absorb.

The cost of retooling and upskilling has become prohibitive to me in the
case of MS products, due to the frequency, magnitude and subtlety of changes
to features and syntax.

Open Source and Linux products also experience specification drift, so there
is still a constant need to retool and upskill, but the cost is
significantly lower IMHO.

Thus the quandry: as an independent service provider, I would like to tyap
into the large MS market, but the cost of doing business there makes it less
attractive than the alternatives. When a client asks my advice, I point this
out and leave them free to decide what to buy based on their own business
imperatives.

Slowly, but increasingly, I see these client buying decisions moving away
from the MS upgrade treadmill.

Just my $0.02
Doug
--
Remove the blots from my address to reply

Nov 13 '05 #96

On 21 Jun 2004 13:58:13 -0700, ja******@oakland.edu (James Fortune) wrote:

....

>- Speed/Variable Declaration tradeoffs encourage large subroutines

This is never an issue for me. The database file operations are generally the
bottleneck in my apps, so I don't need to worry about micro-optimizing my
code. Now, error handling is another matter. I've factored the majority of
my error handler into a class module, but there's still a variable declaration
and a minimum of about 6 lines of error handling block at the end of pretty
much every procedure to get good error info for the developer, and the blocks
are mostly all identical except for the hard-coded procedure name.

The problem is that these monolithic subroutines add complexity. They
can be managed but they are unruly beasts. They are only reusable in
a "cut-and-paste pieces" sense. In one case the most efficient way to
keep code repetition down was to use the old-fashioned GOSUB method
(yuck). Quite often natural places to create new subroutines require
moving many variables to form variables and passing recordsets. It's
not a serious problem but it is a weakness. Being able to break the
code down easily into smaller subroutines adds reliability.

We're totally agreeing here. Duplicated code is a bad thing, and I wish I
could factor it out, but the 6 lines of overhead is as small as I've been able
to whittle it down to - actually, I guess it's 8 lines. This is truly
annoying in the cases of procedures with 1 line of main body. It's hard to
locate the actual code for all the standard overhead.

>Conclusion: For me, Access won't face any serious competition for some
>time.

Well, I agree it -probably won't. It doesn't have any serious competition
now, but I'm not sure why that couldn't change rapidly if someone came along
with the will and a solid, simple design idea that covered most of the bases.

Getting such an OpenSource product up to speed would take a lot of
interaction with users. A new commercial product is more capable of
blindsiding Access.

I didn't mean to imply it would or would not be an open source product, I just
think I've learned better than to try to predict the future.

Nov 13 '05 #97