Access awake after 7 years?

[AnandaSim]

I just had a google through this NG but have not seen mention of Erik
Rucker's blog entry and the new Jet:

http://blogs.msdn.com/access/archive...05/477549.aspx

mentioned by Mike Gunderloy

http://www.larkware.com/dg4/TheDailyGrind726.html

Aside from the Sharepoint feature extension, amazing news.

Ananda

[David W. Fenton]

Steve Jorgensen <no****@nospam. nospam> wrote in
news:02******** *************** *********@4ax.c om:

On Tue, 11 Oct 2005 19:22:39 GMT, "David W. Fenton"
<dX********@bw ay.net.invalid> wrote:

...

When I'm saying enums, I could just as well be saying constants
(though the auto-sense with enums is nice), it's just that enums
are the only kind of constant that can be defined publicly in
-any- version of VBA, . . .
Well, after a certain version of VBA, which I don't use. . .

. . . so that's why I mention them so favorably.
I also try to write code such that enums are not required, but
VBA lacks the OOP features I would usually use as alternatives,
so I end up using enums medium-often.

If I had them, I'd use them, the same way I use the narrowest
possible data types in declaring variables. But not having them is
no more hardship than was lacking a dedicated Boolean data type in
Access 2's Access Basic. Indeed, lacking ENUMS requires
significant ly less working around to verify parameters, because
the code to verify is not much more typing than the definition of
the ENUM itself.

It seems like either I'm not communicating or you're refusing to
read what I'm saying. I am -not- trying to say there's anything
extraordinarily superior about the concept of enums vs the concept
of regular contants.

What I -am- saying is that in Access VBA prior to A2K there was no
way to declare -any- kind of public constant in a class module, be
it a form's module, a report's module, or a stand-alone class. In
A2K and newer, we can declare public enums in a class which is a
way way of declaring public constants in a class module.

Did I now communicate what I'm trying to get across?

Well, I now understand that you're limiting your comments to class
modules, but I'm completely underwhelmed about why it matters. Yes,
it's messy to have to put the public constants for your class module
somewhere else, but no messier than any other global constants that
may or may not be declared in the same module as they are used.
Being able to define the constants in the same module as the
procedures that expect them keeps the definitions (and associated
comments) close to the rest of the closely related code, . . .
Which is very desirable and helpful, but hardly something that is a
deal-breaker in regard to writing good code.
. . . keeps the
proliferation of support modules down, . . .
Again, desirable, but you could easily have a module dedicated to
the purpose of storing public constants for your class modules, with
appropriate comments. So, the proliferation of modules would be
pretty minimal.
. . . and prevents having to copy
a support module to another project along with the object in order
to make it compile.

Well, now, that's a *different* issue. I'm not sure I think it's
wise to have public constants used internally in the class module as
well as by code calling the class module, but perhaps the reason I
wouldn't do it is because I can't.

Hmm. I have to meditate on that one.

I guess it does make sense, since you have to do validity checking
on the input values, and using the declared constants is a good way
to do it.

So, yes, I guess that is an advantage, but, hell, I'm constantly
copying the minimal amount of code from my libraries into new
applications, and I just attempt a compile until I've gotten all the
dependecies removed. That doesn't sound like a huge set of problems
to me, though I certainly agree that this is yet another thing that
would be nice, but still doesn't come close, in my opinion, to
justifying settling on a non-backwardly-compatible Access version.

It's another feature I'd use if I had it, but there are insufficient
such features for me to consider switching format.

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

[David W. Fenton]

Steve Jorgensen <no****@nospam. nospam> wrote in
news:vt******** *************** *********@4ax.c om:

On Tue, 11 Oct 2005 19:22:39 GMT, "David W. Fenton"
<dX********@bw ay.net.invalid> wrote:

...

Are we talking about the same problem? I'm referring to when
the form needs to inform its invoker that something has
happened. If you wrap the form in a class module, all you've
done is move all that coupling into a wrapper.
Well, I can't conceive of a situation where the form needs to
inform the invoker that it wouldn't be a piece of cake to have the
class module doing the informing. Indeed, I'm having a hard time
conceiving of a situation that meets your requirements that is not
a design error in the first place. All the situations that would
be appropriate seem to me to be easy enough to handle through a
class module wrapper what would know it needs to do something to
the invoking form when certain of its properties have been changed
from the invoked form.

Can't coceive of it? I see code like that in almost every
application I work on - particularly in modeless applications.

A really common example is a multi-record view with a separate
modeless form for adding records. . . .

Well, a modeless form for adding records is a design error to me, as
you should be required to complete or abandon the new record before
continuing to another context.
. . . After adding the new record,
the list form should be requeried to display the new record, and
possibly move to the new record.
Even with a modeless new record form (which I think is a completely
mistaken approach -- too easy for the user to accidentally bring
another form to the foreground and then forget that there's a partly
completely record sitting there in the background), I see no reason
why a class module couldn't be used for taking care of
communication. Assuming, for instance, that you can add records a
particular table in many different contexts, and you want to requery
the context from which the add was initiated. Using the class module
as your intermediary, you set up the class in the ADD command button
(recording the calling context and what needs to be requeried), and
the class opens the add record form. When the Add form is closed, it
tells the class that it's closed which then requeries the
appropriate forms, and then it destroys the class instance it was
using.
What I often see in this case is that the new record form directly
requeries the calling form, and seeks to the new record. Often,
this code is broken because it fails to check whether the original
form is still open, fails to be updated when the name or structure
of the calling form has been changed, or fails to account for
other places that it could be opened from. If it does account for
multiple places it could be called from, it gets even more messy.
I don't see how wrapping that in a class does anything but move
the mess to the wrapper class.
It's not a mess if you write the wrapper class correctly. This is
exactly the kind of coding I do all the time for just this kind of
situation (though I would never do a record add in a modeless form).
Now - I will grant you that it's often worth sticking with a
modelal design, so you can use dialog forms and forget that whole
issue and I often do, but sometimes there is a requirement for
modeless.
You're going to have to come up with a different situation than
adding a new record modelessly because I consider that a design
error, because it's too important an operation, and too easy for it
to get lost if it's done modelessly.
When I run across this kind of pathological coupling, I find event
procedures to be an easy way to clean it up. In the case I
described above, the new record form jsut raises an event when the
new record has been added. If the invoking form is holding a
WithEvents reference to it, it can receive that event and decide
what it wants to do about it. If nothing's listening, nothing
happens - perfect.
I see absolutely no advantage to that over a properly constructed
class wrapper, which wouldn't be spaghetti code at all -- all you'd
need in the class is an array of form references that you'd walk
through and requery, and appropriate property LETs for adding to
that array, and appropriate methods when completing the record
addition.

has bothered me about the VBE from the beginning -- it seems to
me that suitability of the existing IDE to Access was sacrificed
for a faux compatibility with other applications where code was
far, far less important, and for which there was simply no
overlap in the direction that would be helpful to those only
familiar with the VBE.

I'm sure that's true, but I'm also sure there has been removal
of code duplication between Access VBA and standard VBA that has
helped MS meet release deadlines, keep from fixing the same bugs
in multiple code bases, etc. I have no where near enough
information to say whether MS made the right decision, but it's
certainly plausible that what they did was the lesser of evils.

The argument here is for having a single codebase for your IDE,
not having an identical IDE in all programs. Those are two
completely different things.

Also, the Access IDE could have been the one that won, rather than
the dumbed-down one.

Again, I'm not saying if MS was right or wrong - I wasn't there,
and I don't know the code internals. It just seems plausible to
me that the road MS chose was the only viable one. Were they
going to try to duplicate the JET storage for module objects in
Word documents? Were they going to change all the other office
apps to be able to open modules in the application's MDI client
window?

You seem to me to be confusing the UI structure with the storage
structure. That can be taken care of with some kind of abstraction
layer between the UI and the host application. Clearly, the VBE
already works that way, since Word and Excel don't store their
modules in the same place or format as Access does.
This is all still a bit rarified from my original point as well,
which was not that I like MS' choice, but that since we have to
live with it, let's at least explore the few new gool goodies that
we got with it.

I don't see where that would be your point. I find A2K+ harder to
use because of the VBE. This makes me less productive.

The argument from code management is neutral on those points, so
really is not in favor of the introduction of the VBE into Access
at all.

You can't know it was neutral anymore than I can know if it was
not - we're both speculating. This is unknowable to us unless we
were to become programmers or architects on the MS Office internal
code base.

Sure, of course it's neutral. Since there's already an abstraction
interface in between the VBE and the host application, the question
is simply a matter of the design of the abstraction layer, and each
host application has a different one anyway. From that point of
view, the VBE is just a "skin" and Microsoft chose the non-Access
"skin" for all the programs. The very acting of choosing a single
"skin" is what gets you the code manageability -- you still have to
maintain the abstraction interface that mediates between the VBE and
the host applications.

BTW, I was googling something completely unrelated and saw that we
already had this discussion in May 2004. I didn't recall it at all,
but we went through exactly the same set of issues in regard to the
VBE.

I'll try to remember not to go on this rant again the next time it
comes up.

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

[aaron.kempf]

i think that you guys are crazy

all the action in the new version of ACCESS-- it has to do with ACCESS
DATA PROJECTS

it is a much more reliable backend for your data

i've just had too mcuh stability problems with a dozen users on Access
MDB

[Steve Jorgensen]

On 13 Oct 2005 17:39:01 -0700, aa*********@gma il.com wrote:

i think that you guys are crazy

all the action in the new version of ACCESS-- it has to do with ACCESS
DATA PROJECTS

it is a much more reliable backend for your data

i've just had too mcuh stability problems with a dozen users on Access
MDB

You're conflating 2 different issues, SQL Server back-end, and Access MDB
front-end. My first Access front end to SQL Server was an MDB, and in spite
of some difficult interfacing, the project went smoothly and was maintainable.
My first attempt to create an ADP was fater doing 3 successful conversions of
MDBs to MDB SQL Server front-ends, and it was a total fiasco. Almost every
hour I spent working on the ADP app was working around something that doesn't
work or doesn't work in the way it needs to. In many cases, things that
worked only worked until some seemingly innocuous change or some update to
MDAC occurred.

Add to that the fact that MS clearly -stopped- doing any useful work on ADP
functionality after Access 2002. None of the bugs that havve dogged em have
been addressed, and no new ADP features have been added. Presumably, MS
noticed that it was costing a lot to try to fix the bugs in the fundamentally
flakey ADP code that hardly anyone is trying to use.

I am still doing new C/S Access development using MDBs, not ADPs.

[lylefair]

Steve Jorgensen wrote:

On 13 Oct 2005 17:39:01 -0700, aa*********@gma il.com wrote: My first attempt to create an ADP was fater doing 3 successful conversions of
MDBs to MDB SQL Server front-ends, and it was a total fiasco. Almost every
hour I spent working on the ADP app was working around something that doesn't
work or doesn't work in the way it needs to. In many cases, things that
worked only worked until some seemingly innocuous change or some update to
MDAC occurred.

Add to that the fact that MS clearly -stopped- doing any useful work on ADP
functionality after Access 2002. None of the bugs that havve dogged em have
been addressed, and no new ADP features have been added. Presumably, MS
noticed that it was costing a lot to try to fix the bugs in the fundamentally
flakey ADP code that hardly anyone is trying to use.

Sadly, I agree; ADPs were a great idea; they seemed to be wonderful. I
was an enthusiastic supporter and contributed to the MS ADP newsgroup.
But as I worked with them more and more I became less and less
enthused. Yes, I found a solution for every problem (except security)
but often after many hours of work; too frequently the solution failed
after one day, or one week, or one month.

I still use ADPs as follows:
1 for trivial personal databases;
2 to mock up web applications and to create sprocs and other objects
for their use (but I'm finding Visual Web Developer is superior for
this);
3. as the base for the wizard creation of DAPs connecting to MS-SQL
dbs;
4. without any base connection to aything; binding forms and reports to
ADO recordsets (this is not so trivial); I think this could be a very
strong development environment for anyone who wants an application
which combines notions of "bound" (we do not bind the form to a
recordsource connected through the project connection, but connect it
to an pristine ado recordset) and unbound (the application itself has
no base connection so it shows no database objects in the db window.)
In this way the developer would assume all responsibilitie s for
security, be it using application roles, crypt functions or whatever.
And of course, one would not be bound to one db as one would not have a
base connection to anything; one could have local tables in MSDE and
remote tables in an MS-SQL server. Some day in my spare time I'll
pursue this (ha ha; if you buy that perhaps you would be interested in
buying a bridge?)

But if a client wanted a MAJOR ADP project I would try to dissuade that
person and move him/her to something else, depending on needs; I would
need some serious money up front and a clear agreement about who was
responsible for the idiosyncracies (and security of the db) of ADPs
(this would not be me) before I would agree; if you think this isn't
going to happen, I think you are right.

[lylefair]

It would be great if you contimued to post in this group, pointing out
the strengths of ADPs and listening patiently to those who have
experienced difficulties with them.
Perhaps, you could (EVEN) adopt a gentler style.

[Bob Alston]

lylefair wrote:

Perhaps, you could (EVEN) adopt a gentler style.

Now is that the pot calling the kettle black.... or what???

[David W. Fenton]

"lylefair" <ly***********@ aim.com> wrote in
news:11******** *************@g 14g2000cwa.goog legroups.com:

Sadly, I agree; ADPs were a great idea; they seemed to be
wonderful.

I don't see that ADPs were ever a great idea. The whole
justification for them seems to me to have been to avoid the icky
old Jet db engine. That so patently stupid an idea that I dismissed
ADPs on the front end, without ever needing to waste hours, days and
weeks trying to make them work.

How, exactly, were ADPs a good idea?

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

[lylefair]

I don't have the patience today to discuss this with someone who is
always right and a complete expert on things he has never used, David.
Because there is no DISCUSSION possible. Upon making a point to such a
person, he will assuredly come up with another issue that supports his
point of view and so on and so on. If he has to, at the end he will
quote scripture: "Michka said ... ". Thanks, but no thanks.

[David W. Fenton]

"lylefair" <ly***********@ aim.com> wrote in
news:11******** *************@g 44g2000cwa.goog legroups.com:

I don't have the patience today to discuss this with someone who
is always right and a complete expert on things he has never used,
David. Because there is no DISCUSSION possible. Upon making a
point to such a person, he will assuredly come up with another
issue that supports his point of view and so on and so on. If he
has to, at the end he will quote scripture: "Michka said ... ".
Thanks, but no thanks.

You drank the Kool Aid.

I didn't.

I'm just pointing out that I was right in my original estimation
that ADPs were of very little value, based on my assessment of the
bogus reasons for *why* they were created in the first place.

You have been the longest-term promoter of ADPs, and now you're off
them, too. It's not my fault that you invested all that time in a
worthless pursuit.

You can call me Howard if I can call you Colin.

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