Eric Rucker hints that Sharepoint is driving Access/Jet features?

[Ananda Sim]

For those who haven't RSSed the blog:

http://blogs.msdn.com/access/archive...13/480870.aspx

[lylefair]

Arggggggg!

[rkc]

Ananda Sim wrote:

For those who haven't RSSed the blog:

http://blogs.msdn.com/access/archive...13/480870.aspx

A lookup field on steroids? What a great idea.

[David W. Fenton]

rkc <rk*@rochester. yabba.dabba.do. rr.bomb> wrote in
news:v1******** ***********@twi ster.nyroc.rr.c om:

Ananda Sim wrote:

For those who haven't RSSed the blog:

http://blogs.msdn.com/access/archive...13/480870.aspx

A lookup field on steroids? What a great idea.

Actually, sounds like a multi-value field, but implemented
behind-the-scenes with a properly normalized structure.

I'm agnostic on this, because the proof is in the pudding -- it all
depends on how it works. Lookups in table definitions sounds like a
good idea until you start using them and find out that they hide the
actual underlying values from you, and that certain Access objects
don't interface with them appropriately.

I also once thought integrating Access with Outlook was a great
idea, but soon figured out that it wasn't scalable and was way too
dependent on Exchange server to be usable for most of my client base
(many of whom don't have a dedicated server).

There's plenty of opportunity to screw up this kind of thing, but
it's also possible for it to be useful. You'd then have the
opportunity, as with lookups in tables, to use it or not.

I can't think that I'll use it myself -- I too often need other
attributes in my N:N join tables -- but we'll wait and see.

Of course, I don't see myself acquiring Longhorn any time soon after
it comes out, so it will all depend on what my clients are doing.
The question for me will be whether or not we'll continue to be able
to program to a set Access file format and have it run in the new
version of Access.

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

[Rick Brandt]

David W. Fenton wrote:

rkc <rk*@rochester. yabba.dabba.do. rr.bomb> wrote in
news:v1******** ***********@twi ster.nyroc.rr.c om:

Ananda Sim wrote:

For those who haven't RSSed the blog:

http://blogs.msdn.com/access/archive...13/480870.aspx

A lookup field on steroids? What a great idea.

Actually, sounds like a multi-value field, but implemented
behind-the-scenes with a properly normalized structure.

I'm agnostic on this, because the proof is in the pudding -- it all
depends on how it works. [snip]

I don't like it. Even if it's normalized "under the covers" it conveys the
notion that multiple vlaues in a field is okay which means that people will also
think it's okay to do the same in cases where the tool is not doing it correctly
behind the scenes.

I feel the same way about the fact that SQL Server now has calculated fields at
the table level. Sure the knowledgeable know that this is just a View in
disguise, but why not just make a View then? Every day in these groups we have
to tell people that you don't store calculations in tables. That effort is
undermined when they look at a "big player" like SQL Server and see calculations
being defined in the tables. It *is* dumbing down and it's just so unnecessary.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[David W. Fenton]

"Rick Brandt" <ri*********@ho tmail.com> wrote in
news:kV******** **********@news svr14.news.prod igy.com:

David W. Fenton wrote:

rkc <rk*@rochester. yabba.dabba.do. rr.bomb> wrote in
news:v1******** ***********@twi ster.nyroc.rr.c om:

> Ananda Sim wrote:
> > For those who haven't RSSed the blog:
> >
> > http://blogs.msdn.com/access/archive...13/480870.aspx
>
> A lookup field on steroids? What a great idea.
Actually, sounds like a multi-value field, but implemented
behind-the-scenes with a properly normalized structure.

I'm agnostic on this, because the proof is in the pudding -- it
all depends on how it works. [snip]

I don't like it. Even if it's normalized "under the covers" it
conveys the notion that multiple vlaues in a field is okay which
means that people will also think it's okay to do the same in
cases where the tool is not doing it correctly behind the scenes.

Doesn't all the db theory going back to Codd and all say that
implementation and presentation is irrelevant to the set theory?
That is, normalization and all that is a goal for performance and
logical structure, and there's no need for its design to leak
through to the level that people actually have to use.

So, I just don't see anything wrong with this. N:N joins are one of
the hardest things for a novice to understand an implement, and the
UIs for it are often quite difficult to design.

I don't know if I'd use it or not, but I can't see anything in
principle that makes it a bad idea to have it available, especially
for novices.
I feel the same way about the fact that SQL Server now has
calculated fields at the table level. Sure the knowledgeable know
that this is just a View in disguise, but why not just make a View
then? Every day in these groups we have to tell people that you
don't store calculations in tables. That effort is undermined
when they look at a "big player" like SQL Server and see
calculations being defined in the tables. It *is* dumbing down
and it's just so unnecessary.

Well, SQL Server and Access are two completely different products. I
don't see why SQL Server should have "user-friendly" features like
that at all, since it's so fricking hard to use in the first place
until you have a pretty good grasp on how databases work already.

So, I'd agree that the SQL Server example is stupid, but think that
since Access is aimed at a completely different audience, this new
feature in Access 12 seems to me that it could be a good thing --
dependent of course, on how well it's implemented and supported
throughout Access.

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

[Rick Brandt]

David W. Fenton wrote:

"Rick Brandt" <ri*********@ho tmail.com> wrote in
news:kV******** **********@news svr14.news.prod igy.com:

David W. Fenton wrote:

rkc <rk*@rochester. yabba.dabba.do. rr.bomb> wrote in
news:v1******** ***********@twi ster.nyroc.rr.c om:

> Ananda Sim wrote:
> > For those who haven't RSSed the blog:
> >
> > http://blogs.msdn.com/access/archive...13/480870.aspx
>
> A lookup field on steroids? What a great idea.

Actually, sounds like a multi-value field, but implemented
behind-the-scenes with a properly normalized structure.

I'm agnostic on this, because the proof is in the pudding -- it
all depends on how it works. [snip]

I don't like it. Even if it's normalized "under the covers" it
conveys the notion that multiple vlaues in a field is okay which
means that people will also think it's okay to do the same in
cases where the tool is not doing it correctly behind the scenes.

Doesn't all the db theory going back to Codd and all say that
implementation and presentation is irrelevant to the set theory?
That is, normalization and all that is a goal for performance and
logical structure, and there's no need for its design to leak
through to the level that people actually have to use.

So, I just don't see anything wrong with this. N:N joins are one of
the hardest things for a novice to understand an implement, and the
UIs for it are often quite difficult to design.

I don't know if I'd use it or not, but I can't see anything in
principle that makes it a bad idea to have it available, especially
for novices.

I feel the same way about the fact that SQL Server now has
calculated fields at the table level. Sure the knowledgeable know
that this is just a View in disguise, but why not just make a View
then? Every day in these groups we have to tell people that you
don't store calculations in tables. That effort is undermined
when they look at a "big player" like SQL Server and see
calculations being defined in the tables. It *is* dumbing down
and it's just so unnecessary.

Well, SQL Server and Access are two completely different products. I
don't see why SQL Server should have "user-friendly" features like
that at all, since it's so fricking hard to use in the first place
until you have a pretty good grasp on how databases work already.

So, I'd agree that the SQL Server example is stupid, but think that
since Access is aimed at a completely different audience, this new
feature in Access 12 seems to me that it could be a good thing --
dependent of course, on how well it's implemented and supported
throughout Access.

My point though is the "typical user" might very well say..."This is okay in
Access 12 so I guess it's also okay in older versions". They'll have no idea
that Access is doing thing properly under the covers. In their eyes they are
simply putting multiple values into a field. I suppose it's not too bad if the
interface for setting it up makes it clear that you are doing something
"special" to give a field that capability.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[David W. Fenton]

"Rick Brandt" <ri*********@ho tmail.com> wrote in
news:ta******** ********@newssv r11.news.prodig y.com:

My point though is the "typical user" might very well say..."This
is okay in Access 12 so I guess it's also okay in older versions".
They'll have no idea that Access is doing thing properly under
the covers. In their eyes they are simply putting multiple values
into a field. I suppose it's not too bad if the interface for
setting it up makes it clear that you are doing something
"special" to give a field that capability.

I thought there was something in Rucker's article that said it would
be a special interface for these fields, He says:

In a single table you could only assign an issue to one person,
and Access would provide a simple bound drop down list of
people to Assign to. With Complex data, you can (still looking
at a single table) assign the issue to several people at the
same time, and Access provides a drop down check list with the
ability to select several people.

Now, so far as I know, we don't yet have a "drop down check list"
control available to us in any version of Access (without, perhaps,
some Stephen Lebans-style extensions), so this sounds like a new UI
control designed for this particular kind of data.

Now, I don't know what this means for datasheets, for instance. I
don't know if you'll be able to manually edit the list like you can,
say, Outlook categories, or if there will be some other mechanism
for it. As I said, whether or not I think it's ultimately a good
thing depends on excatly how they implement it.

As to users taking Access 12 expectations back to earlier versions
of Access, I think this is a relatively minor consideration. How
many people who are novice Access users will:

1. start learning Access only with version 12, AND

2. use these multi-value fields, AND

3. also, after learning Access with version 12, then start working
with earlier versions of Access.

Seems pretty far-fetched to me, and could involve only a very small
number of Access users.

Even if it were a greater temptation, I still don't think preventing
the unknowledgable from making mistakes is a good criterion for
eliminating potentially useful features from Access. I don't really
know if it will be useful to me or not, but I don't think that fear
of misuse is a very good reason for dismissing it before we've even
seen it.

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