1NF Violations *promoted* in MS Access?

"Albert D. Kallal" wrote in
:

At the end of the day, we don't have to use macors, nor do we have
to use these new multi-value fields. I can assumer that a lot of
users will use lookup fields, will use multi-value fields, and
will use macros....none of which I use!!

On the issue of macros, though, aren't they vastly improved, to the
point that they are usable? That is, is it not the case that the
embedded macros have some kind of error handling built in? Certainly
the ability to program a complex action into the event property of
multiple controls at once without having to write a function seems
like a good thing to me. I'm not sure I'd use it a lot, but it does
seem like they've upgraded macros to the point that developers can
at least consider using them in situations beyond the AutoExec macro
and custom menus.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

"Bob Johnson" wrote in
:

If we can never get to those underlying tables, then they might as
well not even exist (given that we could only get to denormalized
views of the data).

But you *can* get to it, albeit only in code.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

"David W. Fenton" wrote in message

On the issue of macros, though, aren't they vastly improved, to the
point that they are usable?

I not looked at the new changes. The largest reason for encouraging macros
now is that one can assume that no vba code is in the appcation. (the idea
is to be able to distribute an data file (or application), and not worry
about having code. Macros can't use the windows api etc, so, they are
consider safe).

A good number of the wizards in a07 now create macro code in place of vba
code for this reason.

I not looked into if macros actually have been improved (I don't know that
answer).


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

I'm actually on board with these MV columns now... not for Albert's reasons,
although they are good, but primarily for the following:

IMHO, the biggest single cause of denormalized and otherwise totally "WTF"
Access table designs is the binding of the UI directly to underlying tables
and queries. The neophyte user only points-n-clicks to create an Access UI.
Binding is their best friend (no code needed). But because of binding they
often (practically all the time that I've seen) design tables to reflect the
UI. Their table designs do not event attempt to correctly model the
real-world entities that should be modeled because they don't know how to do
that and still use binding. 1NF violations galore. You want multiple phone
numbers? Then you get columns like Phone1, Phone2, Phone3, PhoneN. That
story, alone, is told over and over again - thus go the evils of binding
[directly to tables]. Yes, they could jolly well create a 1:M relationship
with a PhoneNumbers table and have a subform, but it frequently doesn't
happen as the 1NF violation is easier for the spreadsheet mentality to grasp
(repeating groups is akin to multiple columns in a spreadsheet).

So, these MV columns can, it appears to me, provide some relief for such a
scenario. Let-em create the MV column for phone numbers. The MV column and
its apparent implementation actually provides an entire abstraction layer
between the user and the *real* underlying normalized tables. Thus we get to
allow the neophytes to employ binding (their best friend) and still get the
correct table design - something many of them would *never* do. Brilliant,
really, now that I think about it. And everybody wins because the seasoned
dba and developer can come along when the whole thing needs to be ported to
something more robust and get to the "real" underlying table structure that
properly implements a normalized design. Nice.

It seems to be we would be within our right minds to *encourage* neophytes
to use MV columns. That way we get normalized data from people who have no
idea of what a normalized table design is or should be - right?


...because, behind the scenese, they've been properly implemented and a
programmer can get access to those behind-the-scenes structures.
And that was my biggest concern. As a programmer migrating data from MS
Access to a more robust solution (I've done a lot of that for many years) I
want to get to the behind-the-scenes structures and pull out normalized
data.


It certainly makes Albert's example query a helluva lot easier, don't you
think?

Yep

-"Bob"



"David W. Fenton" wrote in message
. 1...
"Bob Johnson" wrote in
:

My point isn't to enumerate what I perceive to be the problems of
MS Access. I was just really surprised to see such a blatant
encouragement for users to violate 1NF with these new multi-valued
fields (thus my OP here), and was subsequently referring to other
such ways in which Access promotes the
database-table-is-really-a-spreadsheet mentality to neophytes.

I don't think that multi-value fields are nearly as much of an issue
as lookup tables, because, behind the scenese, they've been properly
implemented and a programmer can get access to those
behind-the-scenes structures. It certainly makes Albert's example
query a helluva lot easier, don't you think?

I won't use them myself, but for end users, I think it really is a
good benefit.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

"David W. Fenton" wrote:

If we can never get to those underlying tables, then they might as
well not even exist (given that we could only get to denormalized
views of the data).

But you *can* get to it, albeit only in code.

You can also get at the multi valued data though using queries. Close
enough for me.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

"Bob Johnson" wrote:

We want to get folks off of spreadsheets.

We all know that some people (heck, *many many many* people; dept
secretaries etc) will *never* get away from their spreadsheet mentality. So
why are we making it easier for them to implement spreadsheet (flat) designs
IN a database? They should just stick with the spreadsheet. At least it's
easier to untangle later on when the app grows and needs to be ported to
something more robust (happens all the time).

But it's easier to understand the multi-valued field and work with it
on a form than creating two new tables and a new form and a subform on
the main form.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Hi , I needed to know how do i make a new dl on OE 6 , If any 1 can help
please do
Thanks
And Take Care
Sarathy

Sorry, this newsgroup is for questions about Access, the database product
that's part of Office Professional.

Your question would be best reposted to a newsgroup that deals with Outlook
Express.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no e-mails, please!)


"Sarathy Arcot" wrote in message
...
Hi , I needed to know how do i make a new dl on OE 6 , If any 1 can help
please do
Thanks
And Take Care
Sarathy