Jet driver version

"Amy Blankenship" wrote in
:

"David W. Fenton" wrote in message
. 1...
"Amy Blankenship" wrote in
:

"David W. Fenton" wrote in
message . 1...

[]

Without any error messages, there's basically no help that
anyone can give you.

At this point there is no way to gather that information.

Then nobody is going to be able to help you.

What is the point
of posting to say you have no intention of being helpful?

I would be happy to offer advice if there were any information
given that would allow me to do so.

But there isn't, and you say there never will be.

I actually said there would not be for _this_ user. Who knows
when/if there will be another user with a similar problem?
However, I find it highly unlikely that _no one_ on this forum has
ever seen a failure of Jet of any kind that they could share a few
thoughts on.

Well, first off, this is an Access forum, where Access programmers
are using Jet. That means they are *not* using ODBC, since Access
refuses to use ODBC to connect to Jet data (since it's native). So
most of us would simply never have encountered any ODBC problems
with Jet.

But even those few who have wouldn't be able to help because you
haven't specified anything at all to narrow down the possibilities.
I understand that you don't *have* any information to narrow down
the possibilities because of your choice to ignore the ODBC error
information in writing your program.

How unprofessional of you to distribute a program without any
error reporting!

It has all kinds of error reporting. It does not have any error
reporting for _this_ situation, because it was not an error I
thought I'd ever need to trap for.

ODBC will return some kind of error information, usually including
an error number and an error description (some of which are not
always terribly illuminating). All you have to do is pick up that
information from ODBC and pass it through to the user.

This is something that's a matter of programming basics,
particularly when utilizing an outside component.

I mean, if you
were posting to say "I have a theory but it could be wrong" that
is one thing, but to post to say that your experience hasn't
prepared you to even offer an idea of what it could be is a
waste of everyone's time.

You're the one wasting people's time, seems to me.

You did not have to respond to my post. If you respond to a post,
it looks to others who might help as if the user is getting help,
so unhelpful posts are actually obstructive. If you can't provide
productive input, it's better not to create the appearance that
you're helping.

I *am* providing help -- I'm pointing out exactly *why* nobody is
likely to be able to help you.

We could just ignore you and offer no responses and then you'd have
no idea why you weren't getting an answer.

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

"Rick Brandt" wrote in
t:

I have only seen that with ODBC sources and in the Runtime
environment so I doubt that your users are seeing the same thing.

She isn't using Access, so your observations don't really have any
relevance.

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

"Amy Blankenship" wrote in
:

I'm frankly quite shocked that with such a huge user base, this
product does not seem to have users at a very high level of
experience answering this type of question. For instance, in
slogging through all the KB articles that are returned when you
type in "DRIVER={Microsoft Access Driver (*.mdb)" in the search
window, I've discovered many interesting facts, for instance:

1) The jet engine starts up on launch of Access itself, but
starts in other applications only when a connection is made (and
presumably halts when the connection is released). This implies
that the Jet engine does not need a service running to be able to
connect,

Well, D'oh! Jet is not a server database engine, so naturally there
won't be any service involved. You clearly don't even understand the
most basic things about the tools you are using.

but there may be unknown factors
involved concerning how that process works in terms of
permissions, etc. 2) The jet engine has memory leaks
3) Some versions of Jet have a path length limitation of 85
bytes, which may be the issue in this case.
4) Sometimes, the Jet engine can be installed in a different
language and thus may not be called "Microsoft Access Driver
(*.mdb)", so attempts to connect to it under that name will fail.
5) TechNet has a whole bunch of utilities that enable you to
look at what the system is doing under the hood so that you can
determine whether surmises such as I made in (1) are correct.

How is it that you guys don't know _any_ of this, as experts (and
you are one recognized by Microsoft as one)? Most of these facts
had nothing at all to do with any error messages someone might
see, so presumably you weren't holding back for lack of error
messages on those.

There's a very good reason:

WE ARE ACCESS DEVELOPERS.

You see up there at the top of your newsreader or on the web page
you're reading? It says the newsgroup name is
microsoft.public.ACCESS. It isn't microsoft.public.Jet or
microsoft.public.Jet.ODBC.

Access can *not* use ODBC to connect to Jet data files because
Access uses Jet natively. Thus, nobody in this group is going to
have any experience with using ODBC with Jet data *unless* that
experience comes from work they do *outside* of Access.

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

"David W. Fenton" wrote in message
. 1...
"Amy Blankenship" wrote in
:

I'm frankly quite shocked that with such a huge user base, this
product does not seem to have users at a very high level of
experience answering this type of question. For instance, in
slogging through all the KB articles that are returned when you
type in "DRIVER={Microsoft Access Driver (*.mdb)" in the search
window, I've discovered many interesting facts, for instance:

1) The jet engine starts up on launch of Access itself, but
starts in other applications only when a connection is made (and
presumably halts when the connection is released). This implies
that the Jet engine does not need a service running to be able to
connect,

Well, D'oh! Jet is not a server database engine, so naturally there
won't be any service involved. You clearly don't even understand the
most basic things about the tools you are using.

You really mean to tell me that there are no services running on your
computer right now that are not related to server functionality? You have a
very odd setup on your computer.

but there may be unknown factors
involved concerning how that process works in terms of
permissions, etc. 2) The jet engine has memory leaks
3) Some versions of Jet have a path length limitation of 85
bytes, which may be the issue in this case.
4) Sometimes, the Jet engine can be installed in a different
language and thus may not be called "Microsoft Access Driver
(*.mdb)", so attempts to connect to it under that name will fail.
5) TechNet has a whole bunch of utilities that enable you to
look at what the system is doing under the hood so that you can
determine whether surmises such as I made in (1) are correct.

How is it that you guys don't know _any_ of this, as experts (and
you are one recognized by Microsoft as one)? Most of these facts
had nothing at all to do with any error messages someone might
see, so presumably you weren't holding back for lack of error
messages on those.

There's a very good reason:

WE ARE ACCESS DEVELOPERS.

You see up there at the top of your newsreader or on the web page
you're reading? It says the newsgroup name is
microsoft.public.ACCESS. It isn't microsoft.public.Jet or
microsoft.public.Jet.ODBC.

So you really think that none of the people ever develop an Access database
for use with other applications or connect to them with Jet? I would not
have expected a product with such a large user base to have such a narrow
focus. In the product that is my core competency, it is very common for
people to have experience in not just the program we use, but also Flash,
Access, ASP, ColdFusion, graphic design, technical writing, and
instructional design. I'm not used to the concept of a one trick pony.
Sorry. It hadn't occurred to me that Access developers would be so narrowly
focused that they wouldn't be more familiar with the technology used to
connect to Access Databases.

-Amy

"Amy Blankenship" wrote in
:

"David W. Fenton" wrote in message
. 1...
"Amy Blankenship" wrote in
:

I'm frankly quite shocked that with such a huge user base, this
product does not seem to have users at a very high level of
experience answering this type of question. For instance, in
slogging through all the KB articles that are returned when you
type in "DRIVER={Microsoft Access Driver (*.mdb)" in the search
window, I've discovered many interesting facts, for instance:

1) The jet engine starts up on launch of Access itself, but
starts in other applications only when a connection is made (and
presumably halts when the connection is released). This implies
that the Jet engine does not need a service running to be able
to connect,

Well, D'oh! Jet is not a server database engine, so naturally
there won't be any service involved. You clearly don't even
understand the most basic things about the tools you are using.

You really mean to tell me that there are no services running on
your computer right now that are not related to server
functionality? You have a very odd setup on your computer.

What the hell are you talking about?

I don't know what youre assumptions about services mean, but the
fact that you don't understand Jet enough to know whether or not it
has dependencies on any running services shows that you shouldn't be
selling your services for developing apps that use Jet data stores.

but there may be unknown factors
involved concerning how that process works in terms of
permissions, etc. 2) The jet engine has memory leaks
3) Some versions of Jet have a path length limitation of 85
bytes, which may be the issue in this case.
4) Sometimes, the Jet engine can be installed in a different
language and thus may not be called "Microsoft Access Driver
(*.mdb)", so attempts to connect to it under that name will
fail. 5) TechNet has a whole bunch of utilities that enable
you to look at what the system is doing under the hood so that
you can determine whether surmises such as I made in (1) are
correct.

How is it that you guys don't know _any_ of this, as experts
(and you are one recognized by Microsoft as one)? Most of these
facts had nothing at all to do with any error messages someone
might see, so presumably you weren't holding back for lack of
error messages on those.

There's a very good reason:

WE ARE ACCESS DEVELOPERS.

You see up there at the top of your newsreader or on the web page
you're reading? It says the newsgroup name is
microsoft.public.ACCESS. It isn't microsoft.public.Jet or
microsoft.public.Jet.ODBC.

So you really think that none of the people ever develop an Access
database for use with other applications or connect to them with
Jet?

I didn't suggest any such thing. But the *majority* of people using
Jet are Access developers, which means they won't have any
experience using ODBC to interace with Jet data.

I would not
have expected a product with such a large user base to have such a
narrow focus.

VB developers wouldn't likely use ODBC, either, as they can use DAO
or ADO. They are the most likely to use Jet who are not Access
developers.

In the product that is my core competency, it is very common for
people to have experience in not just the program we use, but also
Flash, Access, ASP, ColdFusion, graphic design, technical writing,
and instructional design. I'm not used to the concept of a one
trick pony.

Many people *do* have experience using other tools. But most of
those tools won't use ODBC to get to Jet data. The most likely case
where ODBC would be used is, I think, with web developers. There's
not much overlap between Access and web developers, I'd think, since
Access is not Web-friendly.

Sorry. It hadn't occurred to me that Access developers would be
so narrowly focused that they wouldn't be more familiar with the
technology used to connect to Access Databases.

\/\/hatever.

You're obviously using tools you don't understand and are not at all
competent in programming. If you were competent, you'd have the
error messages you needed and would be able to ask a question here
that someone could answer.

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

I've seen 100 failures in jet.

that is why I graduated to SQL Server-- 10 years ago


"Amy Blankenship" wrote in message
...

"David W. Fenton" wrote in message
. 1...
"Amy Blankenship" wrote in
:

"David W. Fenton" wrote in message
. 1...

[]

Without any error messages, there's basically no help that anyone
can give you.

At this point there is no way to gather that information.

Then nobody is going to be able to help you.

What is the point
of posting to say you have no intention of being helpful?

I would be happy to offer advice if there were any information given
that would allow me to do so.

But there isn't, and you say there never will be.

I actually said there would not be for _this_ user. Who knows when/if
there will be another user with a similar problem? However, I find it
highly unlikely that _no one_ on this forum has ever seen a failure of Jet
of any kind that they could share a few thoughts on.


How unprofessional of you to distribute a program without any error
reporting!

It has all kinds of error reporting. It does not have any error reporting
for _this_ situation, because it was not an error I thought I'd ever need
to trap for.

I mean, if you
were posting to say "I have a theory but it could be wrong" that
is one thing, but to post to say that your experience hasn't
prepared you to even offer an idea of what it could be is a waste
of everyone's time.

You're the one wasting people's time, seems to me.

You did not have to respond to my post. If you respond to a post, it
looks to others who might help as if the user is getting help, so
unhelpful posts are actually obstructive. If you can't provide productive
input, it's better not to create the appearance that you're helping.

Thanks;

Amy

you're not used to the concept of a one trick pony?

you're an ART FAG that doesn't understand anything about databases

if you did know ANYTHING about databases; you would use a database SERVICE
and not MDB



"Amy Blankenship" wrote in message
...

"David W. Fenton" wrote in message
. 1...
"Amy Blankenship" wrote in
:

I'm frankly quite shocked that with such a huge user base, this
product does not seem to have users at a very high level of
experience answering this type of question. For instance, in
slogging through all the KB articles that are returned when you
type in "DRIVER={Microsoft Access Driver (*.mdb)" in the search
window, I've discovered many interesting facts, for instance:

1) The jet engine starts up on launch of Access itself, but
starts in other applications only when a connection is made (and
presumably halts when the connection is released). This implies
that the Jet engine does not need a service running to be able to
connect,

Well, D'oh! Jet is not a server database engine, so naturally there
won't be any service involved. You clearly don't even understand the
most basic things about the tools you are using.

You really mean to tell me that there are no services running on your
computer right now that are not related to server functionality? You have
a very odd setup on your computer.

but there may be unknown factors
involved concerning how that process works in terms of
permissions, etc. 2) The jet engine has memory leaks
3) Some versions of Jet have a path length limitation of 85
bytes, which may be the issue in this case.
4) Sometimes, the Jet engine can be installed in a different
language and thus may not be called "Microsoft Access Driver
(*.mdb)", so attempts to connect to it under that name will fail.
5) TechNet has a whole bunch of utilities that enable you to
look at what the system is doing under the hood so that you can
determine whether surmises such as I made in (1) are correct.

How is it that you guys don't know _any_ of this, as experts (and
you are one recognized by Microsoft as one)? Most of these facts
had nothing at all to do with any error messages someone might
see, so presumably you weren't holding back for lack of error
messages on those.

There's a very good reason:

WE ARE ACCESS DEVELOPERS.

You see up there at the top of your newsreader or on the web page
you're reading? It says the newsgroup name is
microsoft.public.ACCESS. It isn't microsoft.public.Jet or
microsoft.public.Jet.ODBC.

So you really think that none of the people ever develop an Access
database for use with other applications or connect to them with Jet? I
would not have expected a product with such a large user base to have such
a narrow focus. In the product that is my core competency, it is very
common for people to have experience in not just the program we use, but
also Flash, Access, ASP, ColdFusion, graphic design, technical writing,
and instructional design. I'm not used to the concept of a one trick
pony. Sorry. It hadn't occurred to me that Access developers would be so
narrowly focused that they wouldn't be more familiar with the technology
used to connect to Access Databases.

-Amy

I guess that means at least one failure in SQL Server. ;-)
--
Jerry Whittle, Microsoft Access MVP
Light. Strong. Cheap. Pick two. Keith Bontrager - Bicycle Builder.

"Tom Wickerqueer" wrote:

I've seen 100 failures in jet.

that is why I graduated to SQL Server-- 10 years ago