My client has just released a system where user records are stored to a
local access database (saved as Access 2000). In the past few days, I have
been getting calls from users where it appears that the most likely cause is
that the correct Jet drivers are not installed. At least one user has
confided that he has Access 97 installed on his computer. How can I check
the Jet version to determine what version he has?
Thanks;
Amy
2) You can use code like this to check the version numbers
change the version numbers to what ever you want: check
whichever files you want.
'David Graham. (david) Right to attribution retained.
'Watch for word wrap
Option Compare Database
Option Explicit
Const mcModuleName = "mdlRP_DLLCheck"
'2003/02/26 dlg
Private Declare Function GetFileVersionInfo& Lib "Version" Alias
"GetFileVersionInfoA" (ByVal FileName$, ByVal lptr&, ByVal lSize&, lpvData
As Any)
Public Sub gsbDLLCheck()
If ("4.0.7328.0" > gfn_GetVersion("msjet40.dll")) Then MsgBox "Warning:
MSJET40.dll is " & gfn_GetVersion("msjet40.dll") ' & ", not SP7"
If ("9.0.0.3822" > gfn_GetVersion("msaccess.exe")) Then MsgBox "Warning:
MSACCESS.EXE is " & gfn_GetVersion("msaccess.exe") ' & ", not SR1"
End Sub
Public Function gfn_GetVersion(FileName$)
'2003/02/26 dlg --minimalist version -- Right to attribution retained
Dim iBuf(0 To 99) As Integer
Call GetFileVersionInfo(FileName$, 0&, 200, iBuf(0))
gfn_GetVersion = iBuf(25) & "." & iBuf(24) & "." & iBuf(27) & "." &
iBuf(26) 'FILE VERSION
End Function
"Amy Blankenship" <Amy_n...@magnoliamultimedia.com> wrote in message
news:%23KWuHgK...@TK2MSFTNGP03.phx.gbl...
>My client has just released a system where user records are stored to a
>local access database (saved as Access 2000). In the past few days, I have
>been getting calls from users where it appears that the most likely cause is
>that the correct Jet drivers are not installed.
What messages are you getting? How did you come to the conclusion
that incorrect Jet DLLs might be the problem?
Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Queries are not returning results, so anything could be the problem. Given
that, it seemed worthwhile to check that the correct jet drivers are
installed.
Without any error messages, there's basically no help that anyone
can give you.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
At this point there is no way to gather that information. What is the point
of posting to say you have no intention of being helpful? 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.
-Amy
> 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.
Here's a theory that's guaranteed to be 100% correct and very helpful to
someone in your shoes:
"You'll get further with honey than you do with vinegar."
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.
"Amy Blankenship" <Amy_n...@magnoliamultimedia.com> wrote in message
news:uxFjYZWn...@TK2MSFTNGP06.phx.gbl...
"'69 Camaro" <ForwardZERO_SP...@Spameater.orgZERO_SPAM> wrote in
message news:O1vLJSZn...@TK2MSFTNGP04.phx.gbl...
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.
"Tom Wickerath MDB" <tom_wi...@hotmail.com> wrote in message
news:eAJ03iZn...@TK2MSFTNGP06.phx.gbl...
I had several reasons for responding as I did:
1) Often, if you get peoples' adrenaline pumping by challenging them on
some level, something will spark in their memories that wouldn't if you were
sweet and nice.
2) He was not actually answering the question posed, so it's difficult to
worry if he's offended. I didn't ask for opinions on whether or not my
theory that Jet was the issue were right, but for people to share their
experiences of circumstances under which Jet might fail.
3) If people see a lot of responses on a thread, they are likely to
consider that the person is getting help and go to the next thread, even if
none of the responses are helpful in any way. So I consider it extremely
rude to answer a question with "No, I can't tell you the answer, but I
consider you stupid to have even asked."
All three of these points apply to your own post as well. Did you have
anything productive to add to the topic at hand?
Thanks;
Amy
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
> news:Xns99398A8B3F69Ef9...@127.0.0.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.
How unprofessional of you to distribute a program without any error
reporting!
> 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.
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
These are discussion groups. You make a post and a discussion follows. If the
discussion proves to be helpful to you that is fine, but you do not get to
dictate the direction, participants, or content of the discussion. It might
feel like "your thread", but that is not the case.
As for your OP, an incompatible version of jet will simply not be able to work
with an MDB file at all. Jet that is the same version, but at a different patch
level might produce some artifacts, but proper queries returning no records
(when they should) without raising error messages is not anything that I have
heard of.
The only thing I can relate that sounds even remotely similar is that I have
seen queries against ODBC sources that are used as ListBox or ComboBox
RowSources fail with an ODBC error that is silent. By that I mean that the
error message that ought to be displayed is not, and the ListBox or ComboBox
simply has a blank list as if the RowSource query had no results.
I have only seen that with ODBC sources and in the Runtime environment so I
doubt that your users are seeing the same thing.
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
You know, somehow I was under the impression it was a support forum.
> As for your OP, an incompatible version of jet will simply not be able to
> work with an MDB file at all. Jet that is the same version, but at a
> different patch level might produce some artifacts, but proper queries
> returning no records (when they should) without raising error messages is
> not anything that I have heard of.
Oh I am sure it does raise error messages. But these messages are not
displayed to the user.
> The only thing I can relate that sounds even remotely similar is that I
> have seen queries against ODBC sources that are used as ListBox or
> ComboBox RowSources fail with an ODBC error that is silent. By that I
> mean that the error message that ought to be displayed is not, and the
> ListBox or ComboBox simply has a blank list as if the RowSource query had
> no results.
Sounds like you're thinking I'm using this from within an Access
application. I'm not.
> I have only seen that with ODBC sources and in the Runtime environment so
> I doubt that your users are seeing the same thing.
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, 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.
-Amy
> All three of these points apply to your own post as well. Did you have
> anything productive to add to the topic at hand?
Of course I do. Being rude and insulting to the many generous expert
volunteers who frequent these newsgroups and try to help those who need it
without charging a penny is one of the quickest ways to get the URL for the
$245 tech support from Microsoft, because your attitude isn't going to
compel very many experienced volunteers to jump to your aid in the future
after reading your messages, even though some of us could have fixed the
problem had it been anyone else's.
http://support.microsoft.com/oas/default.aspx?ln=en-us&x=11&y=12&prid=6689&gprid=36052
Good luck.
Gunny
"Amy Blankenship" <Amy_n...@magnoliamultimedia.com> wrote in message
news:OYVdUUan...@TK2MSFTNGP03.phx.gbl...
If they were actually trying to provide help I'd agree with you, but
unfortunately most of the replies on here have been somewhat in the vein of
"how stupid of you to even think it could be Jet." I say this with the
exception of Tony Toews, who does genuinely appear to be trying to work
towards a solution, and Douglas Steele, who was able to confirm my gut
feeling that Jet does not depend on any running services.
-Amy
David W. Fenton taking the time to say that he isn't prepared to take
the time to answer the question? It's a feature, I'm afraid.
Q. What goes "Idiot. PLONK"?
A. David W. Fenton losing the argument.
Jamie.
--
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.
"Jamie Collins" <jami...@googlemail.com> wrote in message
news:1179995046....@m36g2000hse.googlegroups.com...
XMVP is available these days, if you care to post under another name. ;-)
Gunny
"'69 Camaro" <ForwardZERO_SP...@Spameater.orgZERO_SPAM> wrote in
message news:e%23H4Q4dn...@TK2MSFTNGP05.phx.gbl...
Thanks for coming to my defence!
Q. What did the inflatable Principle say to the inflatable boy who
brought a pin into the inflatable school?
A. "You haven't just let yourself down, you've let me down, you've let
your friends down, you've let the whole school down..."
Jamie.
--
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
> news:Xns9939DE43A5AD5f9...@127.0.0.1...
>> "Amy Blankenship" <Amy_n...@magnoliamultimedia.com> wrote in
>> news:uxFjYZWn...@TK2MSFTNGP06.phx.gbl:
>>
>>> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in
>>> message news:Xns99398A8B3F69Ef9...@127.0.0.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.
> 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.
> 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.
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
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
> news:Xns993A6C59BDF8Bf9...@127.0.0.1...
>> "Amy Blankenship" <Amy_n...@magnoliamultimedia.com> wrote in
>> news:uTZbMkbn...@TK2MSFTNGP05.phx.gbl:
>>
>>> 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.
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.
that is why I graduated to SQL Server-- 10 years ago
"Amy Blankenship" <Amy_n...@magnoliamultimedia.com> wrote in message
news:uCUzUpan...@TK2MSFTNGP02.phx.gbl...
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" <Amy_n...@magnoliamultimedia.com> wrote in message
news:uOi9HMhn...@TK2MSFTNGP04.phx.gbl...