Jamie Collins said:
You seem to be using 'we' to mean 'developers across all MS platforms'
e.g. Visual Studio and Office. I think you comments about ado.net are
misleading in the context of ms-access because AFAIK there is no
practical way of using ADO.NET in an ms-access project whereas ADO
classic remains a viable option.
Sure, I 100% with the above. I was using "we" as a general term
for developers. I was kind of just pointing out that likely more
people are dropping ADO as compared to DAO right now because
that is the new upgrade path for the .net folks.
So, it is apples and oranges, but the message we kind of get
today is that ado.net is the next new thing...and message was
much the same for ado over dao. It not a real big issue because
Microsoft has strongly supports dao in ms-access.
Out of interest, are you recommending the use of the Access2007 multi-
value data types in a standard ms-access project (i.e. other than
sharepoint integration etc)? I've read your opinions on pick, which of
course has the required predicates, but I wondered where you stand on
the Access/Jet implementation of multi-value types. I don't see anyone
in these groups evangelizing or even advocating them. It is relevant
to this thread because you are using them to add to the case for DAO.
I of course am actually a big fan of the muiti-values. to me, many
applications after a number of years begin to start falling apart at the
seams. Fro example, a person has a customer record, and they need to store
their favourite foods. You see the "amateur" developer start adding fields
like food1, food2, food3, or perhaps just one field of food, and in side the
field they type in data like
Apple Pie, Steak, Cheesecake
In both cases, the data is terribly un-normalized. When you use multi-value
fields, your actually normalizing the data. What that means is that after 5
years of a person modifying the database, you don't have to throw it out,
and call in a bunch of high priced oracle experts. So, in a way, those
multi-value fields allow someone to build correctly formed database
structures, and they don't even know it. In fact, I think *any* field should
be able to go multi-value, and the option in the "other" tab that stats what
the enter key does should have a option "allow multi-values on enter key".
(the option now have enter key = new line, I want to see it go: enter key =
new multi value).
In other words, uses should be able to add multi-values to any field, and do
it without barely thinking. The industry falsehood has always been that
multi-value systems are not correctly relational, and not normalized. This
is not true at all. One of the great big secrets of multi-value systems (of
many of which been around for 20, or even 30+ years) is that the designs and
data of the applications where VERY easy to extend over time..so, they did
not being to fall apart at the seems like non normalized applications do
after many years of modifications. As a result, there is TON of old
multi-value systems that continue to run today, when most of the other
vendors from that period have long disappeared. Those old muiti-value
systems continue to run, because their data allowed the applications to be
flexible, and stay *more* normalized then the competing systems of that time
period.
So, I not yet really promoting multi-value fields, but I do believe in them
strongly because they make people actually normalize data without even a
clue to this fact.
In a2007 a person can setup a database with "favourite" foods, and in effect
without having to write one line of code, they actually built that many to
many relation with a junction table without even knowing they were supposed
to -- I think that a huge leap forward for these users.
Users can't think in terms of relational databases, but they sure know that
they want to save a list of favourite foods in their database, and a2007
lets them do that without even realizing they are doing it the right way.
Now, as a seasoned developer, I know how to build that favourite foods list,
so, the really big question becomes will I use this feature? Well, not
likely, not quite yet. However, for a lot of little pick lists, and things
like what category a contact belongs to, those auto-matic pick lists that
a2007 has can actually save developer time also. The problem for seasoned
developers is that the tables and relationships are not exposed in the
relationships windows (however, in dao..and in reocrdset code...they are!!).
This "exposed" part is much a sticking point for me.
Another thing to note is that DAO has still not got enhancements for
some of the Jet 4.0 features (e.g. creating CHECK constraints); ADO
(via the OLE DB providers) has received such enhancements.
Sure, there is a few things in ado that was nicely improved..and mostly done
for those folks coming from sql server. On the other hand..not many of us
use the constraints features. And, the create procedure is really nothing
more
then a select, or saved query anyway.
The popularity of DAO today simply shows that MS could not get rid of it,
and what really amazing is that MS is working hard to keep us happy on this
front. In other words, they simply looked at the market, and access
develops...and said, gee...dao is popular...so, we keep it alive and well.
The beauty is that ms-access gives you a great choice with dao, or ado. I am
thankful to MS for this extra effort and continued support of dao....but,
either one is a fine choice in access.
