Evaluating References in Code [Long]

[jeremygetsmail]

I've got an adp (Metrix.adp) with a reference to another adp
(InteractSQL.ad p). InteractSQL sits on a server, and is refered to by
all of the clients (Metrix), which sit on the client machines (There's
also a SQL Server that sits on the server, but that's besides the point
here.). Both adp files have references to ADOX. I've got to check
Metrix has an older version of ADOX, and react appropriately. I've
written code to do this, and it looks like it should work. But it
doesn't and I can't figure out why.

I would love any thoughts on what might be going wrong with my code. I
would also love any thoughts on other ways that I could go about
assessing what version of ADOX is being refered to in an adp to which
I have a reference set. Another way to go about this would be to figure
out what version of MDAC is on another computer on the network.

The code (below) runs in Metrix, and walks the collection of references
in that file. When it encounters the ADOX reference, it just gathers
the version. When it encounters the InteractSQL reference, it then
walks the reference collection of that object, again gathering the
version number when it finds the ADOX reference.

I've got two machines set up. The client machine has a reference to
ADOX 2.7 in the Metrix file. The InteractSQL file on the server has a
reference to ADOX 2.8 (a scenario we encounter a lot at client sites).
But the code reports back that they are both 2.7. When I go back to
InteractSQL.adp , though, it's reference is clearly still set to 2.8.

Thanks much for any help on this.

Jeremy
--
Jeremy Wallace
Fund for the City of New York

Function fnInteractRepor tRefsValid() As Boolean
On Error GoTo Error
Dim refParent As Access.Referenc e
Dim appChildDB As Application
Dim refChild As Access.Referenc e
Dim lngParentVersio n As Long
Dim lngChildVersion As Long
Dim strInteractFile As String

'Can't know how the references will be named, so get rid of the
extension, if it's there
strInteractFile = Replace(INTERAC TFILE, ".adp", "")

'Walk the collection of references set in Metrix.adp
For Each refParent In References
If refParent.Name = "ADOX" Then
'Gather the local mdac version, which we'll later compare to
the one in interact.
lngParentVersio n = CLng(refParent. Major & "." &
refParent.Minor )
ElseIf refParent.Name Like "*" & strInteractFile & "*" Then
If refParent.IsBro ken = True Then
'Report back if it's broken.
fnInteractRepor tRefsValid = False
Else
'Gather the version of mdac refered to in InteractSQL.adp .
Set appChildDB = New Access.Applicat ion
Call appChildDB.Open AccessProject(r efParent.FullPa th)
For Each refChild In appChildDB.Refe rences
If refChild.Name = "ADOX" Then
lngChildVersion = CLng(refChild.M ajor & "." &
refChild.Minor)
End If
Next refChild
appChildDB.Clos eCurrentDatabas e
End If
End If
Next refParent

If lngChildVersion > lngParentVersio n Then
'Do some stuff
End If

ExitPoint:
On Error Resume Next
'Clean-up code

Exit Function
Error:
'Error handling
End Function

[TC]

Not to answer your question, but, that code will never handle broken
references.

If /any/ refrence is broken, /all/ your VBA code will start to
malfunction. Your code will die, before you even get to check IsBroken.

To avoid this problem, you have to qualify every item that you use in
you code, with the name of the library in which that item occurs. Eg.
you could not say: msgbox "this" & vbcrlf & "that". It would have to be
Access.msgbox "this" & VBA.vbcrlf & "that". (I haven't checked those
library names, they might be wrong, but hopefully you get my point.)

There are other requirments that you have to meet also. It's difficult
- but doable. Google the Access groups for the term "disambigua te" (and
variants) for more information.

HTH,
TC

[jeremygetsmail]

TC,

Yeah, that's true. This is code that I inherited. At some point (though
not before the next release) I'll look into whether or not we should
just pull the IsBroken bit from this code. At this point I can't see
that it hurts much. It's possible that we'll fully disambiguate
everything in the code, but it's thousands of lines of code, so I'm not
holding my breath for that one.

In any case, if any one else has any thoughts about what to do to
return the correct version number from the
reference-within-a-reference, I'd love to hear them.

Thanks much.

Jeremy
--
Jeremy Wallace
Fund for the City of New York

[TC]

Well, I don't have any experience with Access Data Projects (or
whatever they're called) - but this looks wrong to me:

Set appChildDB = New Access.Applicat ion
Call appChildDB.Open AccessProject(r efParent.FullPa th)
For Each refChild In appChildDB.Refe rences

If the references are a property of the access application object, you
would not need to open the access project. Conversly, if the references
are a property of the opened access project, you should save the object
reference that is returned by the OpenAccessProje ct method, and get at
the references though that object reference. IOW your code, as
currently written, is probably looking at the default references
collection that exists in Access /before/ any partiular database or
access project has been opened.

HTH,
TC

[Lyle Fairfield]

je************@ gmail.com wrote:

I would love any thoughts on what might be going wrong with my code. I
would also love any thoughts on other ways that I could go about
assessing what version of ADOX is being refered to in an adp to which
I have a reference set.

If you don't use ADOX and don't set a reference to it you can pretty
much guarantee that the version will be 0000.000.

I don't know of anything that ADOX is needed for with an ADP. (MS-SQL
is extremely powerful!). Do you know of something that requires ADOX?
Could you tell us what it is?

[david epsom dot com dot au]

Looks ok to me:

create new application object

load file into new application object

look at references in new application object.

(david)
"TC" <aa**********@y ahoo.com> wrote in message
news:11******** *************@g 43g2000cwa.goog legroups.com...

Well, I don't have any experience with Access Data Projects (or
whatever they're called) - but this looks wrong to me:

Set appChildDB = New Access.Applicat ion
Call appChildDB.Open AccessProject(r efParent.FullPa th)
For Each refChild In appChildDB.Refe rences

If the references are a property of the access application object, you
would not need to open the access project. Conversly, if the references
are a property of the opened access project, you should save the object
reference that is returned by the OpenAccessProje ct method, and get at
the references though that object reference. IOW your code, as
currently written, is probably looking at the default references
collection that exists in Access /before/ any partiular database or
access project has been opened.

HTH,
TC

[TC]

je************@ gmail.com wrote:

It's possible that we'll fully disambiguate
everything in the code, but it's thousands of lines of code, so I'm not
holding my breath for that one.

You only need to disambiguate the code that checks for broken
references. Typically, this is only a few dozen lines of code. You put
this in a seperate module. The rest of the code (ie. the main code of
the application) is not affected at all.

HTH,
TC

[TC]

And that is precisely his error, imho! He is checking the references
which belong to the application object. He should be checking the
references which belong to the access project that he opened within the
application object. Those are not the same thing. He is checking the
wrong object, imho.

Cheers,
TC

[david epsom dot com dot au]

no, I look at App.References in my code, not
App.CurrentProj ect.references.

I don't know why that is, but there you are.

If MS had implemented App.CurrentProj ect.References,
then they probably could have implemented
App.CurrentProj ect.References( n).References,

Which would have been a useful feature.

Because the two logical helpful things they could
have done are
a) expose all the loaded references in app.references
or
b) expose the indirect references through
currentproject. references(n).r eferences

But references of your references aren't exposed
by the application object by any method - you only
get shown the direct references, and to check the indirect
references you need to create other application objects.

(david)

"TC" <aa**********@y ahoo.com> wrote in message
news:11******** **************@ o13g2000cwo.goo glegroups.com.. .

And that is precisely his error, imho! He is checking the references
which belong to the application object. He should be checking the
references which belong to the access project that he opened within the
application object. Those are not the same thing. He is checking the
wrong object, imho.

Cheers,
TC

[TC]

Ok, let me check I understand what you're saying. You're saying that
the References collection of the Application object, does return the
references of the specific database or access project that is currently
open in that object? So, in the following sequence of actions, steps 3
and 6 would return different information?

1. automate a new instance of Access;
2. open a database or access project in that instance;
3. print all the details of the Application object, Refrences
collecion;
4. close that database or access project;
5. open a different one which definitely does have different references
to the previous one;
6. repeat step 3.

Cheers,
TC