Access 2k3 / WinXP Issue = kooky join

[Steve]

One of our clients recently upgraded their Office version to 2003. When
they tried to run our program (written in Access 2000), they ended up
with the wrong data. My coworker and I have tested this problem and
found that it ONLY occurs on Windows XP machines running Office 2003.
The problem ends up being that ONE 1-to-1 join in ONE query within the
application does not perform as a 1-to-1 join. It acts as though there
is no join at all. There are only two tables in this query - it's a
very simple query. We've tried changing MDAC, checked for updates, and
swapped out DLLs. Nothing fixes the issue. Microsoft's Knowledge base
has no indication of this behavior. Google doesn't return anything
close.

Has anyone else seen this happen in their programs? No other joins have
this problem, so I don't think it's really an issue with the join
itself. We can probably find a way to avoid this problem in future
programs, but we need that relationship to work for this particular
application.

We're getting frustrated and traveling nowhere. It's such a little
thing, but it's causing so much difficulty.

[Allen Browne]

Steve, please provide more info about this.

Post the SQL statement (SQL View of query.)

Are these Access tables in the same database? Attached Access tables?
Attached tables from ....?

For the fields involved in the JOIN, indicate:
- Which is the primary table in the relationship;
- In the Relationships window, when you examine the relationship between the
two tables, which boxes are checked (Relational integrity? Cascading update?
....)
- What is the Field Type (Number, Text, Yes/No, ...) and Field Size of the
field in the primary table.
- What is the Field Type and Field Size of the matching field in the related
table.

Also some basic trouble shooting:
1. Uncheck the boxes under:
Tools | Options | General | Name AutoCorrect
Explanation of why:
http://allenbrowne.com/bug-03.html

2. Compact the database:
Tools | Database Utilities | Compact
This dumps the Name-AutoCorrupt junk, and could also solve the problem if it
were due to a bad index.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Steve" <th*********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

One of our clients recently upgraded their Office version to 2003. When
they tried to run our program (written in Access 2000), they ended up
with the wrong data. My coworker and I have tested this problem and
found that it ONLY occurs on Windows XP machines running Office 2003.
The problem ends up being that ONE 1-to-1 join in ONE query within the
application does not perform as a 1-to-1 join. It acts as though there
is no join at all. There are only two tables in this query - it's a
very simple query. We've tried changing MDAC, checked for updates, and
swapped out DLLs. Nothing fixes the issue. Microsoft's Knowledge base
has no indication of this behavior. Google doesn't return anything
close.

Has anyone else seen this happen in their programs? No other joins have
this problem, so I don't think it's really an issue with the join
itself. We can probably find a way to avoid this problem in future
programs, but we need that relationship to work for this particular
application.

We're getting frustrated and traveling nowhere. It's such a little
thing, but it's causing so much difficulty.

[Steve]

Allen, thank you for responding.

The SQL statement used in this query is:
SELECT ISMF.SPREADKEY, ISMF.CLASSKEY, ISMF.NAME, ISMF.KIND,
ICMF.TCHNAME, ICMF.TCHCODE, ICMF.TCHNUM
FROM ISMF INNER JOIN ICMF ON ISMF.CLASSKEY = ICMF.CLASSKEY
WHERE (((ISMF.KIND)="S"));

Table ISMF is the closest thing to a primary table we have in this
query. The one join in the query does not have referential integrity or
cascading updates turned on.
Both keys are Number fields, size Double.

The result of this issue is that the number of records produced by this
query is about 5 times as many as there should be. There should be
roughly 1600 records in the result; there are 8650. As stated earlier,
this query works perfectly fine in Access 2000 and Access 2002 in
Windows 2000 or XP. It works in Access 2003 when running Windows 2000.
As soon as Access 2003 and Windows XP are combined, this query produces
the extra records.

Thank you for your suggestions - I tried them, and checked out your
page on name AutoCorrect. It turned out that the database did not have
name AutoCorrect turned on, but I tried your suggestions anyway.
Unfortunately, the problem still exists.

-Steve

[David W. Fenton]

"Allen Browne" <Al*********@SeeSig.Invalid> wrote in
news:43***********************@per-qv1-newsreader-01.iinet.net.au:

2. Compact the database:
Tools | Database Utilities | Compact
This dumps the Name-AutoCorrupt junk, and could also solve the
problem if it were due to a bad index.

It will also dump the compilation of the query, which may have been
optimized in a way that is not compatible with the new version of
Access.

A compact is the first thing I would recommend for any case where a
query is returning different data on different machines.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"Steve" <th*********@gmail.com> wrote in
news:11**********************@g49g2000cwa.googlegr oups.com:

Thank you for your suggestions - I tried them, and checked out
your page on name AutoCorrect. It turned out that the database did
not have name AutoCorrect turned on, but I tried your suggestions
anyway. Unfortunately, the problem still exists.

Have you tried recreating the query in A2K3?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Allen Browne]

Okay, Steve. As you said in original post, that's a pretty straightforward
query statement.

You did not tell us whether ISMF and ICMF are Access tables, or attached
tables, and if attached what kind of database. That could have a bearing,
e.g. the ODBC drivers could be different in the 2 versions of Windows.

JET could also be different. You might like to locate msjet40.dll (typically
in windows\system32), right-click and choose Properties, and look on the
Version tab. You should see 4.0.8xxx.0. The xxx digits don't matter, but if
you don't see the 8, download SP8 for JET 4 from:
http://support.microsoft.com/kb/239114

You are probably aware the Single and Double types are subject to rounding
errors, and that this makes them unreliable for joins. If these are Access
tables in the same mdb, try creating the relation (Tools | Relationships)
with enforced referential integrity. My guess is that Access will not allow
you to do it, because of the minor differences between the floating point
values.

Defining the relation with referential integrity also defines the direction
of the relation (i.e. which is the primary table in the one-to-one
relation.)

If you need no more than 4 decimal places, the Currency field (a fixed-point
type) would be okay. Don't use Decimal: JET has no idea how to handle that
type.

These extra records that it generates: how close are ISMF.CLASSKEY and
ICMF.CLASSKEY in these records? Are they close enough to be rounding errors
(e.g. first 14 significant figures are the same)?

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Steve" <th*********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

Allen, thank you for responding.

The SQL statement used in this query is:
SELECT ISMF.SPREADKEY, ISMF.CLASSKEY, ISMF.NAME, ISMF.KIND,
ICMF.TCHNAME, ICMF.TCHCODE, ICMF.TCHNUM
FROM ISMF INNER JOIN ICMF ON ISMF.CLASSKEY = ICMF.CLASSKEY
WHERE (((ISMF.KIND)="S"));

Table ISMF is the closest thing to a primary table we have in this
query. The one join in the query does not have referential integrity or
cascading updates turned on.
Both keys are Number fields, size Double.

The result of this issue is that the number of records produced by this
query is about 5 times as many as there should be. There should be
roughly 1600 records in the result; there are 8650. As stated earlier,
this query works perfectly fine in Access 2000 and Access 2002 in
Windows 2000 or XP. It works in Access 2003 when running Windows 2000.
As soon as Access 2003 and Windows XP are combined, this query produces
the extra records.

Thank you for your suggestions - I tried them, and checked out your
page on name AutoCorrect. It turned out that the database did not have
name AutoCorrect turned on, but I tried your suggestions anyway.
Unfortunately, the problem still exists.

-Steve

[Steve]

Thank you for your reply. We have run the compact and repair utility
numerous times after attempting different solutions. We've also tried
creating the query again in Access 2003 on the WinXP machine. The
result ends up the same.

Allen, ISMF and ICMF are linked dBASE IV tables. This facet has been
under scrutiny for a while, but the tables themselves appear to be
linking without any problems or data corruption. Jet and MDAC have been
updated (rather, 'attempted to update' - the updates won't apply if
your system is already at the latest version). I checked the
msjet40.dll file as per your suggestion anyway, and it's at 4.0.8618...
The keys in ISMF and ICMF are exactly the same. They are single-digit
numbers, no decimals, nothing larger than 9. I can only assume they are
coming in as Double types because of the link to the dbIV table. As
such, I can't change them, unfortunately.

Thanks to your post, I just thought of something we haven't tried. I'm
going to copy the dBASE IV data into Access tables and try the query on
the Access tables instead of going directly through the linked tables.
This should bypass any issues with the ODBC driver as a result of this
particular query. Noting such, I would think that if there truly was
something wrong with the driver, none of the queries in the database
would be returning the correct results.

Thank you for taking your time to assist with this issue.

-Steve

[Steve]

Well, copying the data in the linked tables into local tables and
running the query off of them worked just fine. However, another
problem cropped up that may very well be related to the same root
cause: CurrentProject.Connection causes a "class not registered" error.
All the research I've done indicates that something is very wrong with
Jet or even OLE DB. I've gone through every Knowledge Base article I
could find and all the forums available through Google and the only
solution offered is to update Jet 4.0 to SP8 and MDAC to 2.8, both of
which have already been done. We're setting up another test machine now
to see if we can find a solution for this.

In any case, if someone else has this problem in the future and reads
this, at least they will have a shortcut to the real issue at hand
instead of going through a bunch of hoops like we have.

[Allen Browne]

Interesting, Steve.

CurrentProject.Connection should be a simple enough ADO reference. Try:
? References("ADODB").FullPath

That should give you the path to the ADO library, and the version of
msado21.tlb on my dev machine shows at 2.81.1117.0. If the library looks
right, you may be able to uninstall it and reinstall with regsvr32.

If the key fields are actually integer types in dBase IV, you could try
typecasting the values in the SQL statement. It will be very inefficient,
and Access won't be able to show the query graphically, but you could try:
SELECT ISMF.SPREADKEY, ISMF.CLASSKEY, ISMF.NAME,
ISMF.KIND, ICMF.TCHNAME, ICMF.TCHCODE, ICMF.TCHNUM
FROM ISMF INNER JOIN ICMF
ON CLng(ISMF.CLASSKEY) = CLng(ICMF.CLASSKEY)
WHERE (ISMF.KIND ="S");

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Steve" <th*********@gmail.com> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com...

Well, copying the data in the linked tables into local tables and
running the query off of them worked just fine. However, another
problem cropped up that may very well be related to the same root
cause: CurrentProject.Connection causes a "class not registered" error.
All the research I've done indicates that something is very wrong with
Jet or even OLE DB. I've gone through every Knowledge Base article I
could find and all the forums available through Google and the only
solution offered is to update Jet 4.0 to SP8 and MDAC to 2.8, both of
which have already been done. We're setting up another test machine now
to see if we can find a solution for this.

In any case, if someone else has this problem in the future and reads
this, at least they will have a shortcut to the real issue at hand
instead of going through a bunch of hoops like we have.

[Steve]

Thank you for the suggestions, Allen.

I checked the ADO library using the command you indicated, and found
the reference pointing to msado15.dll, which appears to be the correct
file. The msado21.tlb type library and msado15.dll have the same
version number: 2.81.1117.0, which seems to be the same version as
yours.

Using regsvr32, I unregistered and then re-registered msado15.dll. When
I opened Access and ran the affected part of the program, the "class
not registered" error still broke the code. I've done a bit of quick
research on msado15.dll and msado21.tlb, and it seems most the
available information is from quite a while back. The articles keep
mentioning ADO 2.0 and 2.1, which is a far cry from the 2.8 I'm working
with. I've already tried using 2.7, as there were a few articles
regarding issues with versions <2.6 from a year or two ago, but that's
not making the grade either.

I appreciate the help you've offered. We will eventually find a way to
make this program work in Access 2k3 on Windows XP. We may go crazy
first, but a positive result will come eventually.

-Steve

[Lyle Fairfield]

Steve wrote:

Thank you for the suggestions, Allen.

I checked the ADO library using the command you indicated, and found
the reference pointing to msado15.dll, which appears to be the correct
file. The msado21.tlb type library and msado15.dll have the same
version number: 2.81.1117.0, which seems to be the same version as
yours.

Using regsvr32, I unregistered and then re-registered msado15.dll. When
I opened Access and ran the affected part of the program, the "class
not registered" error still broke the code. I've done a bit of quick
research on msado15.dll and msado21.tlb, and it seems most the
available information is from quite a while back. The articles keep
mentioning ADO 2.0 and 2.1, which is a far cry from the 2.8 I'm working
with. I've already tried using 2.7, as there were a few articles
regarding issues with versions <2.6 from a year or two ago, but that's
not making the grade either.

I appreciate the help you've offered. We will eventually find a way to
make this program work in Access 2k3 on Windows XP. We may go crazy
first, but a positive result will come eventually.

-Steve

I'm sitting here trying to remember when and where I saw and was
confused by this "class not registered" error with respect to ado. It's
clouded but I think this this is it:

I had a reference to another file (mdb in this case but I doubt it
matters). It had a reference to ado 2.x (x=something, probably 8). In
the main file I also had a ref to ado 2.x (x=x). When I changed one of
these references to ado 2.y (probably 7) everything worked. I can't
verify this right now and it's more than possible that I am
hallucinating. (I also don't have the whole thread available so
apologies if what I'm saying has already been covered, or is not on
topic at all).
I know this is a long shot, but, you might like to consider it.

--
Lyle Fairfield

[Allen Browne]

Lyle, I also struck something obsure like that, and can't recall the detail.
Seems like I had to unregister the libraries, hack the reg, clean up, and
re-register.

Steve, you could try this simplified sequence:
1. Deselect ADO 2.8 in your mdb. Close Access.
2. Unregister msado15.dll
3. Register msado21.tlb
4. Open the app, and reference ADO 2.8.
5. Verify that it is now using msado21.tlb
6. See if it made any difference.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Lyle Fairfield" <ly***********@aim.com> wrote in message
news:qi****************@read1.cgocable.net...

Steve wrote:

Thank you for the suggestions, Allen.

I checked the ADO library using the command you indicated, and found
the reference pointing to msado15.dll, which appears to be the correct
file. The msado21.tlb type library and msado15.dll have the same
version number: 2.81.1117.0, which seems to be the same version as
yours.

Using regsvr32, I unregistered and then re-registered msado15.dll. When
I opened Access and ran the affected part of the program, the "class
not registered" error still broke the code. I've done a bit of quick
research on msado15.dll and msado21.tlb, and it seems most the
available information is from quite a while back. The articles keep
mentioning ADO 2.0 and 2.1, which is a far cry from the 2.8 I'm working
with. I've already tried using 2.7, as there were a few articles
regarding issues with versions <2.6 from a year or two ago, but that's
not making the grade either.

I appreciate the help you've offered. We will eventually find a way to
make this program work in Access 2k3 on Windows XP. We may go crazy
first, but a positive result will come eventually.

-Steve

I'm sitting here trying to remember when and where I saw and was confused
by this "class not registered" error with respect to ado. It's clouded but
I think this this is it:

I had a reference to another file (mdb in this case but I doubt it
matters). It had a reference to ado 2.x (x=something, probably 8). In the
main file I also had a ref to ado 2.x (x=x). When I changed one of these
references to ado 2.y (probably 7) everything worked. I can't verify this
right now and it's more than possible that I am hallucinating. (I also
don't have the whole thread available so apologies if what I'm saying has
already been covered, or is not on topic at all).
I know this is a long shot, but, you might like to consider it.

--
Lyle Fairfield

[Steve]

Lyle, thank you for your input. This Access application doesn't have
any references to any outside files that can have their own references
defined. I went through the reference list and the only references used
are to Microsoft files (i.e. MS ADO, etc.). I've dropped it back down
to ADO 2.7 anyway, though, and it doesn't seem to change anything. The
CurrentProject.Connection object existed before Access 2003 ever did,
so I would think that 2.7 would still have that object, whereas ADO 1.0
might not. I haven't been programming long enough to know about that :)

Allen, again, thank you for your suggestions. I ran across a number of
your posts today while tracking down different solutions. I'd like to
thank you for taking the time to help other people with their technical
issues.

I'm afraid I'm going to sound like more the dolt here because I don't
know how to register a type library. The information I've found on the
subject indicates that this can only be done with third-party tools. If
this is the case then I will certainly obtain said utilities and
register the type library. I noticed, though, if I add a reference to
msado21.tlb, the description comes up as Microsoft blah blah blah 2.1,
instead of MS ADO 2.8. This seems like a step backwards. Is it, or am I
simply witnessing one of the many Microsoft quirks?

-Steve

[Lyle Fairfield]

If you get nowhere I recommend downloading and running on the problem
machine(s) the MDAC Component Checker available at
http://msdn.microsoft.com/data/mdac/...s/default.aspx
It's painless to download and run; interpreting the results can be a
little challenging but basically you can find out: I'm OK or I'm not
OK.

[David W. Fenton]

"Allen Browne" <Al*********@SeeSig.Invalid> wrote in
news:43***********************@per-qv1-newsreader-01.iinet.net.au:

CurrentProject.Connection should be a simple enough ADO reference.
Try:
? References("ADODB").FullPath
CurrentProject is not part of the ADO library. It's a member of
Access itself, as well as a member of Access.Application.

This is very similar to the way Access also has a DBEngine that is
separate from the DBEngine that is a member of DAO. Note also that
CurrentDB is a member of Access.Application, not of DAO.

So these kinds of things should never cause errors unless the base
Access installation itself is badly hosed.
If the key fields are actually integer types in dBase IV, you
could try typecasting the values in the SQL statement. It will be
very inefficient, and Access won't be able to show the query
graphically, but you could try:
SELECT ISMF.SPREADKEY, ISMF.CLASSKEY, ISMF.NAME,
ISMF.KIND, ICMF.TCHNAME, ICMF.TCHCODE, ICMF.TCHNUM
FROM ISMF INNER JOIN ICMF
ON CLng(ISMF.CLASSKEY) = CLng(ICMF.CLASSKEY)
WHERE (ISMF.KIND ="S");

I'm wondering why CurrentProject is relevant in the first place, as
it has nothing to do with the way Access is communicating with dBase
files, which use the Jet dBase ISAM.

I've seen that get completely corrupted and hosed on machines in the
past, in a way that is irreperable, and required re-installing a
fresh copy of Windows and re-installing all the software.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"Steve" <th*********@gmail.com> wrote in
news:11**********************@g47g2000cwa.googlegr oups.com:

I checked the ADO library using the command you indicated, and
found the reference pointing to msado15.dll, which appears to be
the correct file. The msado21.tlb type library and msado15.dll
have the same version number: 2.81.1117.0, which seems to be the
same version as yours.

Using regsvr32, I unregistered and then re-registered msado15.dll.
When I opened Access and ran the affected part of the program, the
"class not registered" error still broke the code. I've done a bit
of quick research on msado15.dll and msado21.tlb, and it seems
most the available information is from quite a while back. The
articles keep mentioning ADO 2.0 and 2.1, which is a far cry from
the 2.8 I'm working with. I've already tried using 2.7, as there
were a few articles regarding issues with versions <2.6 from a
year or two ago, but that's not making the grade either.

I appreciate the help you've offered. We will eventually find a
way to make this program work in Access 2k3 on Windows XP. We may
go crazy first, but a positive result will come eventually.

Not sure why ADO 1.5 would relevant. That's the ADO version that
used to be the one that was compatible with Access97, and that's the
only context I've seen it used in. ADO 2.1 is the version for Access
2K and higher, in my experience, but ADO is not my thing -- I use
DAO exclusively.

I also can't quite figure out why you think ADO has anything to do
with accessing dBase files, which are supported by the Jet dBase
ISAM, if I'm not mistaken.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"Steve" <th*********@gmail.com> wrote in
news:11**********************@g14g2000cwa.googlegr oups.com:

Lyle, thank you for your input. This Access application doesn't
have any references to any outside files that can have their own
references defined. I went through the reference list and the only
references used are to Microsoft files (i.e. MS ADO, etc.). I've
dropped it back down to ADO 2.7 anyway, though, and it doesn't
seem to change anything. The CurrentProject.Connection object
existed before Access 2003 ever did, so I would think that 2.7
would still have that object, whereas ADO 1.0 might not. I haven't
been programming long enough to know about that :)

CurrentProject is a member of the Access object and a member of the
Access.Application object. You don't need an ADO reference to have
it available to you.

I strongly suggest that you rebuild the machine exhibiting the
problem. I've in the past seen machines with problems with accessing
DBFs that were completely unsolvable. We spend hours and days trying
to tweak this and that, and never succeeded. We eventually installed
a fresh copy of Windows (not by reformatting, just by installing to
a different Windows folder), and then re-installed Office and all
the other software, and then DBFs worked as expected.

However, this was with Access97, but surely it's worth a try if you
don't succeed in fixing it through all the other tweaks you're
attempting.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Steve]

Thanks to both of you for your detailed assistance. It sounds like I'm
best off if Office 2k3 is reinstalled. I hope this will fix the issue,
as I'd hate to reinstall Windows on this machine. If I must I must,
though, because I need to be able to run Access applications on it.

Thank you both again for your help.

-Steve

[Lyle Fairfield]

I guess that's your choice, but I'd run the component checker first (it
takes about a minute).

[Allen Browne]

Uninstalling Access (Office), and then re-installing would cause the library
to re-register as others suggested.

Before you go that far, you could try unregistring the old library. To do
that, open a command prompt and enter:
regsvr32 /u "C:\Program Files\Common Files\System\ADO\msado15.dll"
Then register the other library instead:
regsvr32 "C:\Program Files\Common Files\System\ADO\msado21.tlb"

In between those steps, you might need to search the registry (run RegEdit)
for ADO 2.8.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Steve" <th*********@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

Lyle, thank you for your input. This Access application doesn't have
any references to any outside files that can have their own references
defined. I went through the reference list and the only references used
are to Microsoft files (i.e. MS ADO, etc.). I've dropped it back down
to ADO 2.7 anyway, though, and it doesn't seem to change anything. The
CurrentProject.Connection object existed before Access 2003 ever did,
so I would think that 2.7 would still have that object, whereas ADO 1.0
might not. I haven't been programming long enough to know about that :)

Allen, again, thank you for your suggestions. I ran across a number of
your posts today while tracking down different solutions. I'd like to
thank you for taking the time to help other people with their technical
issues.

I'm afraid I'm going to sound like more the dolt here because I don't
know how to register a type library. The information I've found on the
subject indicates that this can only be done with third-party tools. If
this is the case then I will certainly obtain said utilities and
register the type library. I noticed, though, if I add a reference to
msado21.tlb, the description comes up as Microsoft blah blah blah 2.1,
instead of MS ADO 2.8. This seems like a step backwards. Is it, or am I
simply witnessing one of the many Microsoft quirks?

-Steve

[Steve]

Based on Allen's prior suggestions and research done online, I've
already unregistered and re-registered msado15.dll. regsvr32 refuses to
register msado21.tlb. The error message says the the DllRegisterServer
entry point cannot be found, and then it states that msado21.tlb does
not appear to be a DLL or OCX file (which, obviously, it's not). Thusly
I am unable to register msado21.tlb using regsvr32.

I'm reinstalling Office 2k3 right now. In theory, as Allen noted, this
should cause all the necessary DLLs and such to be registered
correctly.

Thank you both again for your extensive help on this issue. I'll let
you know whether or not this procedure does the trick.

[Steve]

All right, so I uninstalled and then reinstalled Office 2k3, had the
same problem, and ran the Component Checker. All files check out OK, so
it looks like I'm going to have to either get deeper into this or
reinstall Windows. We're setting up another XP/Office 2k3 machine now
to see if the problem still exists when Office 2k3 is installed on a
clean install of WinXP.

[Lyle Fairfield]

Reinstall Windows? I thought Condoleeza committed the USA NOT to
practice torture. You must be from another country?

[David W. Fenton]

"Steve" <th*********@gmail.com> wrote in
news:11**********************@o13g2000cwo.googlegr oups.com:

Thanks to both of you for your detailed assistance. It sounds like
I'm best off if Office 2k3 is reinstalled. I hope this will fix
the issue, as I'd hate to reinstall Windows on this machine. If I
must I must, though, because I need to be able to run Access
applications on it.

If you reinstall Office 2K3, I would strongly suggest that you
uninstall it first and then run the Office cleanup utility, if there
is one (there is one for O97 and O2K, at least). If the machine
perhaps had an earlier version of Office on it, you might want to
try running the cleanup utility for that version, too, before
reinstalling Office 2K3.

However, in the situation where I was having problems, uninstalling
made no difference -- DBF support was still broken, and that's why
we had to do a clean Windows install.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[david epsom dot com dot au]

I see that the further discussion indicates an
installation problem, and I am not a dBase user,
but,

Did you have the BDE installed?

What version of dBase?

Do you have index files?

Are the tables linked as files, or as ODBC connections?

(david)
"Steve" <th*********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

One of our clients recently upgraded their Office version to 2003. When
they tried to run our program (written in Access 2000), they ended up
with the wrong data. My coworker and I have tested this problem and
found that it ONLY occurs on Windows XP machines running Office 2003.
The problem ends up being that ONE 1-to-1 join in ONE query within the
application does not perform as a 1-to-1 join. It acts as though there
is no join at all. There are only two tables in this query - it's a
very simple query. We've tried changing MDAC, checked for updates, and
swapped out DLLs. Nothing fixes the issue. Microsoft's Knowledge base
has no indication of this behavior. Google doesn't return anything
close.

Has anyone else seen this happen in their programs? No other joins have
this problem, so I don't think it's really an issue with the join
itself. We can probably find a way to avoid this problem in future
programs, but we need that relationship to work for this particular
application.

We're getting frustrated and traveling nowhere. It's such a little
thing, but it's causing so much difficulty.

[Steve]

I downloaded the Windows Installer Clean-Up utility, the description of
which specifically indicated that it can be used for Office 2003
uninstalls, but when I ran it after uninstalling Office, there was no
entry for MS Office. Since the tool only shows programs that used
Windows Installer to initially install, I must assume that the install
information from Office 2k3 simply is not there anymore.

David E., it does look like an installation issue. I'm using dBASE IV.
The appropriate index files exist, and the tables are linked as ODBC
connections. The problem now is the CurrentProject.Connection object
throwing the "class not registered" error. It seems to be
machine-specific (i.e. just THIS machine, of course!), which is
consistent with the 'installation problem' theory.

[David W. Fenton]

"Steve" <th*********@gmail.com> wrote in
news:11**********************@g47g2000cwa.googlegr oups.com:

David E., it does look like an installation issue. I'm using dBASE
IV. The appropriate index files exist, and the tables are linked
as ODBC connections. The problem now is the
CurrentProject.Connection object throwing the "class not
registered" error. It seems to be machine-specific (i.e. just THIS
machine, of course!), which is consistent with the 'installation
problem' theory.

I assume you've deleted the INI files that describe the indexes and
tried recreating them by choosing the indexes when relinking? That
should throw a different error if it's the source of the problem,
but it's worth a look.

Of course, I'm also still confused about why you are using ADO or
ODBC instead of just using Jet. Is this an ADP? I went back and
checked all your posts and you never said that it is, so if it is,
then you've really omitted absolutely crucial information.

If it's an MDB, then I have no clue why you're using such
non-optimal methods for connecting to DBF files.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Deb]

Somewhere I read that the Jet engine may be at fault -- but since you
are not using Jet. . .

Check the Knowledgebase for Jet Fixes anyway

[David W. Fenton]

"Deb" <ko*****@swbell.net> wrote in
news:11**********************@g44g2000cwa.googlegr oups.com:

Somewhere I read that the Jet engine may be at fault -- but since
you are not using Jet. . .
Is it not a Jet ISAM that provides access to DBF files, even if one
is using that ISAM through ADO?

Or is there a separate ADO provider for DBFs?

Or ODBC?
Check the Knowledgebase for Jet Fixes anyway

No one should be running Jet 4 with anything other than SP6 or SP8,
whether they are dealing with DBFs or not.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[david epsom dot com dot au]

I think that I am outside my comfort zone here, but
I think that he is using ACCESS-JET-ODBC not ACCESS-JET-IISAM.

So I think we can rule a out specific Jet IISAM problems.

The reported problem is with linked ODBC tables. It seems
to me that the problem is in the DB files, ODBC driver,
or in Access.

Since the problem seems to be specific to one machine (?)
it could be a problem with the data files or permissions.
(including the way the indexes are working, since it seems
to be specifically an index failure).

If it is an ODBC problem, I'm not sure where the dbase ODBC
driver comes from: is it part of Jet? MDAC? Office? If
the user is using the Borland Database Engine (aka BDE,
aka Paradox :~), the dbase ODBC drive came from Borland

There was originally no reason to suspect anything wrong
with the Access side of the linked tables, but the reported
problem with .Connection is suspicious. It is well known
that comm object reference problems in VBA can cause any
number of odd errors, so perhaps the same has happened to
the linked tables.

(david)
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196. 97.142...

"Deb" <ko*****@swbell.net> wrote in
news:11**********************@g44g2000cwa.googlegr oups.com:

Somewhere I read that the Jet engine may be at fault -- but since
you are not using Jet. . .

Is it not a Jet ISAM that provides access to DBF files, even if one
is using that ISAM through ADO?

Or is there a separate ADO provider for DBFs?

Or ODBC?

Check the Knowledgebase for Jet Fixes anyway

No one should be running Jet 4 with anything other than SP6 or SP8,
whether they are dealing with DBFs or not.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Steve]

Thank you all for your responses.

This is an MDB, not an ADP. The reason we use ODBC is so multiple users
can read and write to the db IV files at the same time. The problem
seems to really have nothing to do with the db IV side now, especially
since the program has been tested on another machine with the same db
IV files with no problems at all. David Epsom, I believe you are right
about the common files causing problems in this case. The root issue
seems to be a problem with a common DLL.

[David W. Fenton]

"Steve" <th*********@gmail.com> wrote in
news:11*********************@o13g2000cwo.googlegro ups.com:

Thank you all for your responses.

This is an MDB, not an ADP. The reason we use ODBC is so multiple
users can read and write to the db IV files at the same time. The
problem seems to really have nothing to do with the db IV side
now, especially since the program has been tested on another
machine with the same db IV files with no problems at all. David
Epsom, I believe you are right about the common files causing
problems in this case. The root issue seems to be a problem with a
common DLL.

I still don't understand what all your worries about ADO libraries
has to do with ODBC, then. ADO and ODBC are completely unrelated and
don't overlap at all, so far as I'm aware.

It could be that the ODBC libraries are different on the two
machines. I've seen that, too, but only in cases where the Access
ODBC drivers were not getting installed for some reason (I needed
them for mail merge from Word, since DDE is unacceptable).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Steve]

ADO and ODBC could theoretically overlap as an ADO connection can be
used with an ODBC connection string.

The problem doesn't seem to be with ODBC, OLE DB, the connection
string, etc. It appears to be a problem with the DLLs related to the
Connection object.

[David W. Fenton]

"Steve" <th*********@gmail.com> wrote in
news:11*********************@z14g2000cwz.googlegro ups.com:

ADO and ODBC could theoretically overlap as an ADO connection can
be used with an ODBC connection string.

The problem doesn't seem to be with ODBC, OLE DB, the connection
string, etc. It appears to be a problem with the DLLs related to
the Connection object.

Those are Access DLLs, surely, since the Connection object belongs
to the Access object or the Access.Application object. I'd think,
though, that those would actually be wrappers around some other form
of functionality, as the DBEngine object under Access.application is
a wrapper around Jet functionality that's also exposed as a member
of DAO.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc