D
David W. Fenton
Or it could be a case where the DDL is supported in ADO but not in
DAO, as is the case with some data types that I forget.
Or it could be a case where the DDL is supported in ADO but not in
DAO, as is the case with some data types that I forget.
L
Larry Linson
Jamie Collins said:In summary, you seem to be saying, "I could but I won't." Fair
enoughThanks for considering it, though.
In fact, I passed on your question in a private newsgroup for Access MVPs.
One of my MVP colleagues confirmed that one of the examples in Help (about
an item you mentioned) did not work. I suggested if any of the MVPs who read
it had a response for you, they respond directly in the thread, which I
identified. As none have responded here, so far, I can only suggest
**again** that you use the facilities in Help to communicate with Microsoft.
Unless I have have a specific question, have personally tested a reported
error, validated that it fails, and my MVP colleagues have reproduced the
error, I would not presume on my relationship with anyone at Microsoft. I
do no work, in general, in DDL and little in ADO*, so I would have to invest
more time and effort to pursue your issues than I am prepared to invest.
And, I am not convinced that any but an infinitesimally small minority of
Access users would ever use those features, so "wider applicability of an
answer" is not an incentive, either.
* Being an Access MVP does not require that one be, nor
imply that one is, expert in every area of Access. It is a
product with many, many facets, features, and capabilities,
and it is unlikely that anyone is "expert in every area".
From your discussions, I draw the conclusion that you use DDL to create
databases and database objects because you do NOT use Access, but other UIs,
even in database design. So, this would also fall beyond what I perceive to
be appropriate questions for this newsgroup and I note that you have "agreed
to disagree" on that issue.
I find that there are rarely answers to "why" questions for any vendor's
software -- they are often taken as accusations that the vendor deliberately
did something wrong, whether or not that was the questioner's intent.
In the past, books have been published that dealt with the Jet database
engine. There is a good deal of documentation freely available from
http://support.microsoft.com and http://msdn.microsoft.com, though I don't
know if any of it will meet your criteria.
In the meanwhile, my guess is that the obvious answer as to "why" those
things are in Help and not supported is simply that "they are but are not".
I have been privileged to meet some of the Help team at Microsoft, and am
convinced that they do take into account the responses we can provide
through the Help system. So it's possible, if you do offer a suggestion on
improving the usability of Help, that it will result in a change.
For your information, a quick search of newsgroups in the microsoft.public
hierarchy showed 5 newsgroups related to VB and database, one related to VC
and database, and one related to Visio database modeling.
Larry Linson
Microsoft Access MVP
L
Larry Linson
David W. Fenton said:
I was operating under the assumption that Jamie was discussing ADO.
Larry
J
James A. Fortune
Jamie said:
I'm not usually verbose but I feel that I need to respond in kind
.I think I'll comment in a future post about CLR versus T-SQL functions.
I've read the articles and though about your suggestions. The articles
deal mostly with where security and data integrity occur for the data.
I think that it's a good thing that the Access/Jet and SQL worlds are
being forced to do some merging. Access/Jet users have been able to get
by with using less formal methods than our SQL user counterparts. This
is one of the reasons why I think your input is valuable. As someone
who used to do most things using recordsets in VBA, I found doing the
same things in SQL to be much more elegant yet less powerful.
C.f.:
http://groups.google.com/group/comp.databases.ms-access/msg/48c6295af8c00685
Consequently, I began more and more to accomplish things in SQL
realizing that it is more scalable, yet to use VBA for the thorniest
problems hoping that the VBA code would give me some clues about how to
write equivalent SQL later. Having learned SQL from the Access/Jet
side, I was constrained by the limitations of Access/Jet SQL when
experimenting. Furthermore, Microsoft never took pains to reveal the
existence of CHECK constraints. I think that the CHECK constraints are
simply an awareness thing. No Access/Jet user seems to think they are a
bad idea, but no one's been using them. I think they will be a great
habit for Access/Jet users to develop.
In one of our previous discussions:
http://groups.google.com/group/microsoft.public.access/browse_frm/thread/a80488dffe168b09
I noted that the time history table approach will require too much
maintenance/complexity in SQL for the average Access developer until the
SQL-3 standards get implemented.
Although I've had undergraduate and graduate courses in programming, my
formal training is in applied mathematics and mechanical engineering. I
think that is one of the reasons people can understand me
. Inmathematics and computer programming I have seen that formalism can be
taken to extremes. Both engineering and mathematics have a formalism
about how to know whether something is correct or not. Much engineering
thought deals with intuition, testing and a kind of Socratic checklist
that seems to parallel CHECK constraints. For instance, when using
numerical methods for fluids problems a check is made on each discrete
"differential" volume to make sure that basic engineering equations like
conservation of mass still hold within the numerical method so that
numerical instabilities can be detected or prevented. Like with CHECK
constraints, I agree that formalism, per se, should not be discouraged.
In practical situations I have to balance the requirements with how
much formalism I allow noting that formalism usually increases the
abstract level, and hence the complexity, of the application. I know
that I need to increase continually the amount of formalism of my
applications, but I also have to get my work done. I'll have to ease
CHECK constraints into my work habits. I designed a SQLServer backend
for an e-commerce app in 1999 and was fortunate enough to get by with
slightly modified Access/Jet techniques. As the Access/Jet and SQL
worlds continue to merge I hope to find a happy medium with methods that
are a little more formal than what I currently use. Again, thanks for
your help on this path.
James A. Fortune
(e-mail address removed)
L
Larry Linson
Yours is a long and interesting reply.
Please note that my objection to Jet-no-Access or ACCDB-no-Access issues or
topics in the microsoft.public.access newsgroups is not with questions about
them, as you imply -- no one is obligated to respond to them so we can
ignore them if we wish, and I most often do. And, if that is the question
that's asked, you don't find me admonishing you about answering it. (As with
any post, I may well respond if I believe a response to be in error and/or
misleading, no matter who posted the erroneous or misleading answer.)
My objection is to responses that imply they could solve the poster's
problem, but are in fact only remotely, if at all, related to the question
that was about the Access-Jet or Access-ACDB environment. Unfortunately, you
and I "cross words" over those because you repeatedly insert such topics
into threads where they only a digression, confusing and misleading the
poster or other participants.
If you'd post those topics as original posts or questions, or in answer to
questions about the environment to which they apply, you wouldn't be
interfering with the purpose of the newsgroup to the extent that hijacking
the threads does. And, perhaps to your surprise, you'd find that I really do
leave the issue of "topicality" up to whoever at Microsoft is in charge of
the microsoft.public hierarchy.
(However, you'll find that many of us here will offer the suggestion to
posters whose question is clearly off-topic that they'd stand a better
chance of getting a useful answer elsewhere.)
Yes, it's not always easy to see the results, even when the feedback does
"influence the future". You may rest assured that Microsoft gets "loud and
clear" response from its MVP community when Help is not what we perceive to
be "up to snuff", but the responses via the facilities of the Help system
are in some Microsoft employees job performance "measurement" so they _will_
be read and evaluated.
And, when the finite resources are expended on changing the Help engine (as
they were in the past, from WinHelp to HTML Help) at the expense of content,
it is very frustrating.
There are many areas in which software vendors use that "finite resource" to
address issues that are more likely to affect what they consider their
"mainstream customers" for the product, rather than pursuing a "purist"
ideal for people who aren't in that category. It can also be very
frustrating to discover that the vendor's idea of who are the "mainstream
customers" is different from yours. The fact that you can see that their
emphasis and lack of emphasis makes perfect sense from their point of view
doesn't make it any less frustrating. I have, unfortunately, had that
experience from time to time since before there were any microcomputers.
I agree that it would be nice to have a detailed specification of software
functionality, but I know that is rare, indeed, for such to be published for
commercial software. And that has been the case since the beginning of the
"computer business". It is even rarer for software for which the common
perception is "nice little desktop database".
Standards are good, and there may be some implementation that truly conforms
to the standards. Notice I use the singular, because I'm reasonably sure
that I've never encountered any commercial software that did. It's just too
tempting for vendors or implementers to add their own "flavor" to their
product.
Ah, yes, the power of "global text find-and-replace". I once had an
acquaintance whose first name was "August", but in a revision to his local
telephone book, he became "September".
But, now, the designation of "Access database" will not necessarily be a
misnomer. Now that the Access team "inherited" Jet from the separate group
who previously "owned" it in Microsoft, and derived ACCDB from it, there is
a real, genuine "Access database."
But, "portability" is rarely the answer to any question in this newsgroup,
and this isn't the venue to campaign for it or champion it. In fact, for
most of the database upscaling in which I've been involved, portability was
not a significant issue; it's an issue primarily in the enterprise
environment, in which there may be a number of different "front ends" (UI or
otherwise) to the same database. But, no surprise, the number of
less-than-enterprise implementations vastly outnumbers the enterprise
implementations.
And, for most of the posters here, to invest time and energy in portability
is expensive, fruitless folly. It is important to you, it is important to
others, and has even been important to me at times (but because of my
changing client base, it is less important to me now than before).
And, I think we have long-since exhausted the usefulness of continuing this
admittedly-far-off-topic meandering. I wish you well. I hope you'll consider
moving the no-Access stuff to threads where it clearly applies, or to
initiate new threads. For this thread, I am inclined to "give you the last
word".
Regards,
Larry
Please note that my objection to Jet-no-Access or ACCDB-no-Access issues or
topics in the microsoft.public.access newsgroups is not with questions about
them, as you imply -- no one is obligated to respond to them so we can
ignore them if we wish, and I most often do. And, if that is the question
that's asked, you don't find me admonishing you about answering it. (As with
any post, I may well respond if I believe a response to be in error and/or
misleading, no matter who posted the erroneous or misleading answer.)
My objection is to responses that imply they could solve the poster's
problem, but are in fact only remotely, if at all, related to the question
that was about the Access-Jet or Access-ACDB environment. Unfortunately, you
and I "cross words" over those because you repeatedly insert such topics
into threads where they only a digression, confusing and misleading the
poster or other participants.
If you'd post those topics as original posts or questions, or in answer to
questions about the environment to which they apply, you wouldn't be
interfering with the purpose of the newsgroup to the extent that hijacking
the threads does. And, perhaps to your surprise, you'd find that I really do
leave the issue of "topicality" up to whoever at Microsoft is in charge of
the microsoft.public hierarchy.
(However, you'll find that many of us here will offer the suggestion to
posters whose question is clearly off-topic that they'd stand a better
chance of getting a useful answer elsewhere.)
Yes, it's not always easy to see the results, even when the feedback does
"influence the future". You may rest assured that Microsoft gets "loud and
clear" response from its MVP community when Help is not what we perceive to
be "up to snuff", but the responses via the facilities of the Help system
are in some Microsoft employees job performance "measurement" so they _will_
be read and evaluated.
And, when the finite resources are expended on changing the Help engine (as
they were in the past, from WinHelp to HTML Help) at the expense of content,
it is very frustrating.
There are many areas in which software vendors use that "finite resource" to
address issues that are more likely to affect what they consider their
"mainstream customers" for the product, rather than pursuing a "purist"
ideal for people who aren't in that category. It can also be very
frustrating to discover that the vendor's idea of who are the "mainstream
customers" is different from yours. The fact that you can see that their
emphasis and lack of emphasis makes perfect sense from their point of view
doesn't make it any less frustrating. I have, unfortunately, had that
experience from time to time since before there were any microcomputers.
I agree that it would be nice to have a detailed specification of software
functionality, but I know that is rare, indeed, for such to be published for
commercial software. And that has been the case since the beginning of the
"computer business". It is even rarer for software for which the common
perception is "nice little desktop database".
Standards are good, and there may be some implementation that truly conforms
to the standards. Notice I use the singular, because I'm reasonably sure
that I've never encountered any commercial software that did. It's just too
tempting for vendors or implementers to add their own "flavor" to their
product.
Ah, yes, the power of "global text find-and-replace". I once had an
acquaintance whose first name was "August", but in a revision to his local
telephone book, he became "September".
But, now, the designation of "Access database" will not necessarily be a
misnomer. Now that the Access team "inherited" Jet from the separate group
who previously "owned" it in Microsoft, and derived ACCDB from it, there is
a real, genuine "Access database."
But, "portability" is rarely the answer to any question in this newsgroup,
and this isn't the venue to campaign for it or champion it. In fact, for
most of the database upscaling in which I've been involved, portability was
not a significant issue; it's an issue primarily in the enterprise
environment, in which there may be a number of different "front ends" (UI or
otherwise) to the same database. But, no surprise, the number of
less-than-enterprise implementations vastly outnumbers the enterprise
implementations.
And, for most of the posters here, to invest time and energy in portability
is expensive, fruitless folly. It is important to you, it is important to
others, and has even been important to me at times (but because of my
changing client base, it is less important to me now than before).
And, I think we have long-since exhausted the usefulness of continuing this
admittedly-far-off-topic meandering. I wish you well. I hope you'll consider
moving the no-Access stuff to threads where it clearly applies, or to
initiate new threads. For this thread, I am inclined to "give you the last
word".
Regards,
Larry