DAO vs ADO

[Mary Chipman]

I find it amazing that you've saved all that old stuff. Well, times
sure have changed since then. For one thing, I don't do flame wars any
more and I learned where the shift key is located on the keyboard

ADO will be around for a while, but it's definitely not the way of the
future. If you're looking forward, think "managed code". It basically
boils down to, if Microsoft has a large installed base of customers
out there using a particular technology, then it will continue to be
supported, if not forever, then for a while longer. I don't see VB6
(or even Jet) dying quite as quickly as some have predicted. I
wouldn't necessarily recommend new development in deprecated
technologies, but I wouldn't recommend re-writing something that works
from the ground up either. FWIW, Access isn't a deprecated technology
per se, although certain features may be. They're already planning
v.next in Redmond. Whether that version will support developer
features compatible with or competitive with .NET is anyone's guess at
this point.

--Mary

 

[Craig Alexander Morrison]

Mary

I have a select collection (only 100 Threads, about 1500 messages) of
discussions mainly about Relation Database Design from late 1993 to early
1995 which is fairly constant in this changing world. They were collected in
an Access database that started life in 1993 (Version 1.1) and was available
for general download in 1994 to 1995 (Version 2.0).

That was a time when relational databases first came to the desktop with the
introduction of Access, not perfect but streets ahead of the competition.

All of my professional production systems from Access 2.0 have converted up
to each subsequent "good" version with very few problems. I would expect
this to continue even if the .NExT thing is a fairly dramatic shift.

I have been taking some time out from live developments to "play" with the
SQL Server 2005 BETA and was reviewing which old databases I would "play"
with. I now have a Access 2003 application that front ends a SQL Server 2005
database of my original Access 1.1 CompuServe Threads. At the same time I
have been revisiting the newsgroups and saw both your name and a
conversation not a million miles from the "Use Primary Key?" thread, titled
"Rule when Primary Key is needed?".

I notice that quite a few of the old names from the CompuServe days had or
have gone on to write books about and around Access, have you all got
nothing better to do. (vbg)

All the best.

--
Slainte

Craig Alexander Morrison

I find it amazing that you've saved all that old stuff. Well, times
sure have changed since then. For one thing, I don't do flame wars any
more and I learned where the shift key is located on the keyboard

ADO will be around for a while, but it's definitely not the way of the
future. If you're looking forward, think "managed code". It basically
boils down to, if Microsoft has a large installed base of customers
out there using a particular technology, then it will continue to be
supported, if not forever, then for a while longer. I don't see VB6
(or even Jet) dying quite as quickly as some have predicted. I
wouldn't necessarily recommend new development in deprecated
technologies, but I wouldn't recommend re-writing something that works
from the ground up either. FWIW, Access isn't a deprecated technology
per se, although certain features may be. They're already planning
v.next in Redmond. Whether that version will support developer
features compatible with or competitive with .NET is anyone's guess at
this point.

--Mary

snipped...

 

[Mary Chipman]

Most of the folks from the old Compuserve Access MVP crowd has moved
on to either .NET or SQL Server or both, except Viescas, who I believe
is still active in the Access ng's. My last book was several years ago
now, but the basic concepts of how to build an efficient Access-SQL
app haven't changed since then, so it's still useful info for many
people. I probably won't write another one any time soon. It's a lot
of work to do a good one with original research that isn't just a
rehash of the help files. Even though our book is still selling, the
hourly rate for the time we expended compares unfavorably with the
hourly rate for flipping burgers

If you're interested, these days you'll get the livliest discussions
on relational design in the microsoft.public.sqlserver.programming
newsgroup, where Joe Celko livens up many a thread.

Your Access FE should work fine with SQLS 2005 as long as you're
running in 2000 compatibility mode. It's unclear at this point if
Access will ever have full support for new features like CLR
assemblies and UDTs. There's only so much you can tack on to what is
essentially an ancient architecture. How much has really changed in
the last 10 years?

--Mary

 

[Lynn Trapp]

Even though our book is still selling, the

hourly rate for the time we expended compares unfavorably with the
hourly rate for flipping burgers

That's kind of like the hourly rates for teachers. Still, I can assure you
that you are much more appreciated by your audience than any burger flipper
ever was by their customers.

 

[Steve Jorgensen]

Most of the folks from the old Compuserve Access MVP crowd has moved
on to either .NET or SQL Server or both, except Viescas, who I believe
is still active in the Access ng's. My last book was several years ago
now, but the basic concepts of how to build an efficient Access-SQL
app haven't changed since then, so it's still useful info for many
people. I probably won't write another one any time soon. It's a lot
of work to do a good one with original research that isn't just a
rehash of the help files. Even though our book is still selling, the
hourly rate for the time we expended compares unfavorably with the
hourly rate for flipping burgers

I suppose you have to factor in how the name recognition factors in to your
billing rate though, eh? I see your book on a lot of book shelves, including
my own.

If you're interested, these days you'll get the livliest discussions
on relational design in the microsoft.public.sqlserver.programming
newsgroup, where Joe Celko livens up many a thread.

As do the opinions about Joe Celko. In learning about Agile database design,
though, I'm starting to sympathize more with some of what Joe says. Just
because a system will "probably" end up benefiting from surrogate keys at some
point is no reason to throw them in before they actually "are" needed
(provided that cascade update is available). It complicates the front-end
system without any proven benefit.

 

[Mary Chipman]

That's kind of like the hourly rates for teachers. Still, I can assure you
that you are much more appreciated by your audience than any burger flipper
ever was by their customers.

 

[Mary Chipman]

Once you've got the name recognition, there's really no need to do
another book unless it's revising the first one, which doesn't take as
much effort. I emailed the publisher last year to see if they were
interested, and they never even bothered to answer. As for billing
rates, it never made much difference because clients don't read tech
books and don't care. And now that I have a FT job, I don't have to
worry about money-grubbing

--Mary

 

[Craig Alexander Morrison]

Mary

If you're interested, these days you'll get the livliest discussions
on relational design in the microsoft.public.sqlserver.programming
newsgroup, where Joe Celko livens up many a thread.

In the past I have had my differences with Joe as he comes from the SQL side
rather than the Relational side. Some may not be aware that SQL is not
(wholly) relational. One shudders to think what CLR could do it could even
allow Joe and I to agree on something. (vbg) On the 10 year old thread I
mentioned earlier Joe and I came to blows on the problems associated with
not defining a Primary Key. Our disagreement was based on him coming from
the SQL side and me from the Relational side, we were both right in our own
terms. I think Joe now agrees more with the relational side. Having had a
look at his recent contributions on the above newsgroup I find little to
disagree with. Mind you, give me time. (vbg)

Regarding little ol' Access, whilst the architecture may be 10 years old it
is (roughly) based on Relational Theory which is over 30 years old and is
still relevant.

Your Access FE should work fine with SQLS 2005 as long as you're
running in 2000 compatibility mode.

What's the problem with 2002/2003 in this respect?

It's unclear at this point if Access will ever have full support for new
features like CLR assemblies and UDTs. There's only so much you
can tack on to what is essentially an ancient architecture.

However a tool like Access is required to allow users and database
developers to be able to harness the power of the new database engines. We
certainly do not want to have to rely on programmers with little
understanding of set theory and their love of record numbers and "so-called"
surrogates.

Note: A true surrogate (from say a hashing algorithm) is hidden to the user
and that includes the developer, it is system generated and internal. It
allows the database developer to pick the real natural Primary Key even if
that is fairly complex and the system hashes this to some internal value
that is then used to refer to this value in all relationships.

How much has really changed in the last 10 years?

Very little on the theory side. If anything the theory is becoming better
implemented, I may have to leave SQL Server 2005 out of that generalisation
though. I am not sure if SQL Server 2005 has blown it or not, anyway I am
also playing with the latest version of DB2 (UDB 8.2 aka Stinger due for
general release on 17 September) which seems to be streets ahead. DB2 is
where I came in to this field nearly 20 ago, a homecoming may be in the
offing.

Most of the folks from the old Compuserve Access MVP crowd has moved
on to either .NET or SQL Server or both, except Viescas, who I believe
is still active in the Access ng's. My last book was several years ago
now, but the basic concepts of how to build an efficient Access-SQL
app haven't changed since then, so it's still useful info for many
people. >

Well I thought that SQL Server 2000 was a promising start but SQL Server
2005 looks rather disappointing after a whole 5 years in the works. DB2
still looks like the only serious contender (if you forget about Oracle and
I am still trying to. (g))

Access is a wonderful front end development tool for database developers
maybe we could let all the programmers go and use whatever the latest
flavour of the month is while we remain using a tool that started out pretty
good from the start and has improved ever since but less and less with each
"good" release as it was pretty strong by Access 97. There was hope for
the ADP in 2002 which I had hoped would make access to SQL Server 2000 more
like using the next version of Jet. We sort of referred to SQL Server 2000
as Jet 5.

P.S. My brother is a programmer who started out at IBM developing OS/2 and
is now up to his neck in .NET and all that and we do get on, honest. I
like programmers, some of my best friends are programmers but if they touch
my database design they are dead! (vbg) And if they trawl through a
recordset when they could have used SQL they are taken out back and beaten
to within an inch of their life. (vbg) Relational Theory Hard but Fair.

DAO or ADO I try not to use either as much as possible, SQL will do just
fine for me most of the time. RQL would be better!

I probably won't write another one any time soon. It's a lot
of work to do a good one with original research that isn't just a
rehash of the help files. Even though our book is still selling, the
hourly rate for the time we expended compares unfavorably with the
hourly rate for flipping burgers

The problem with perfectionists is that they damage their hourly rate by
being unprepared to a slap dash job.

All the best.

--
Beatha agus Slainte

Craig Alexander Morrison


comments inline above.

 

[Mary Chipman]

I didn't mean that you'd necessarily *agree* with Celko, any more than
the SQLS MVPs do, just that it would be interesting

I meant SQLS 2000 compatibility mode, not Access.No version of Access
will support the new SQLS 2005 features.

SQLS 2005 probably is a disappointment for many who were looking for
features other than developer-oriented functionality. But the emphasis
in this version has been on managed code and getting the CLR hosted
inside the SQLS engine. There is some new SQL syntax, like
Access-style xtab queries, and other features like notifications,
database mirroring, etc. However, DB2 also looks pretty interesting as
well. We shall see.

--Mary

 

[Craig Alexander Morrison]

I didn't mean that you'd necessarily *agree* with Celko, any more than

the SQLS MVPs do, just that it would be interesting

Well I do find Joe's comments nowadays more in line with my understanding
and experience. Perhaps he has seen the light

No version of Access
will support the new SQLS 2005 features.

Is that _NO VERSION_ ever?

--
Slainte

Craig Alexander Morrison


snipped

 

[Mary Chipman]

No version of Access

Is that _NO VERSION_ ever?

To the best of my knowledge, ADPs will not support the
table/view/stored procedure designers, now or ever. You should still
be able to use them to connect to a Yukon database, just not create
objects in it. Naturally you won't get any of the new functionality,
only data that is SQLS 2000-compatible.

--Mary

 

[kitti]

kitti