Does anybody have experience with MS Access deployments in a
Citrix environment?

On one of my apps, a mystery problem has arisen.

A certain form, when opened, throws "2467: The expression you
entered refers to an object that is closed or doesn't exist."
at line 2002 of the code at the bottom of this post.

But here is the zinger: the error only occurs when two of the
users are logged in to Citrix from their own PCs. It does not
occur for me, and it does not occur when I log into Citrix from
my own PC using their user IDs.

On the face of it, it does not seem like Citrix should be
user-PC-dependent... but there it is.

Anybody seen anything like this?

Here is the offending code:
---------------------------------------------------
Private Sub pickList_Create()
2000 DebugStackPush Me.Name & ": pickList_Create"
2001 On Error GoTo pickList_Create_err

' PURPOSE: To create/re-create the form's picklist
' in light of the report "As-Of" date

2002 Dim myQuery As DAO.QueryDef

2010 Me.subList.Form.RecordSource = ""

2020 WorkTable_Create
"ttblGet_ReportSpecs04_CompanyGroupPickList",
"zmtblGet_ReportSpecs04_CompanyGroupPickList"

2030 Set myQuery =
CurrentDb.QueryDefs("qryGet_ReportSpecs04_CompanyG roupPickList_Populate")
2031 With myQuery
2032 .Parameters("theAsOfDate") = Me.txtDate
2033 .Execute dbFailOnError
2039 End With

2049 DoEvents

2999 Me.subList.Form.RecordSource =
"qryGet_ReportSpecs04_CompanyGroupPickList_Lis t"

pickList_Create_xit:
DebugStackPop
On Error Resume Next
myQuery.Close
Set myQuery = Nothing
Exit Sub

pickList_Create_err:
BugAlert True, ""
Resume pickList_Create_xit
End Sub
---------------------------------------------------


FWIW, that code is being called from Form_Open().
But remember: it only fails sometimes - depending
on the PC that is logged into Citrix.

viz:
---------------------------------------------------
Private Sub Form_Open(Cancel As Integer)
1000 DebugStackPush Me.Name & ": Form_Open"
1001 On Error GoTo Form_Open_err

' PURPOSE: - To initialize the form's "AsOf" date
' - To create the subform's pick list
' - To initialize various semaphore fields

1002 Dim myUserID As String
Dim myDate As Variant

1010 gDateSpecified = Null
1011 gModalDialogOutcome = False
1019 Forms!frmHome!txtAsOfDate = Null

1020 With Me.txtDate
1021 .Value = BizDay_Previous_Nth(Date, 1)
1022 .SetFocus
1029 End With

1030 pickList_Create

1060 mIsFirstSearch = True
1999 DoCmd.Hourglass False

Form_Open_xit:
DebugStackPop
On Error Resume Next
Exit Sub

Form_Open_err:
BugAlert True, ""
Resume Form_Open_xit
End Sub
---------------------------------------------------
--
PeteCresswell

Hi Pete

I have to access all MSOffice products via a Citrix Web Interface and we
have problems right across all of the Office suite...

If I try and access any MSOP's via Citrix WI from home, I have all manner of
hassles as I run 2007 and they run 2003.

Aside from that, have you compared Reference Libraries to see if anyone
has/has not got them enabled...

HTH
Mick.

Per Vacuum Sealed:
Actually, last week we had a problem with just that.

Magically, two references had been added to the application"
"Microsoft Office XP Web Components" and "Microsoft Office Web
Components 11.0". That was OK for all users except for one -
and for that user one of the references was broken, apparently
the file was not on Citrix' virtual PC for them. I removed the
refs (which were not being used) and all was well.

But that was pretty clearly Citrix-User-Specific.

This one seems to be PC-specific bc for both users who get the
error, I can log on to Citrix from my own PC with their IDs and
the problem does not occur.

As counter-intuitive as it may be, it seems like maybe Citix is
getting more than just the user's DefaultPrinter from the user's
PC. "Seems".... being the operative word bc I know so little
about Citrix that it's basically "magic" to me.
--
PeteCresswell

Pete

I understand & feel your pain everytime I saddle up in the chair......

Good luck with it..

Cheers
Mick

"(PeteCresswell)" <x@y.Invalid> wrote

Citrix can also use the local drives and ports. Open the Citrix client on
both computers to verify they match. Then, when logged into Citrix, check
which local resources are available.

O.T. we switch from Citrix/Terminal server to Hyper-v; so much easer to
setup, each user gets an workstation that is almost like a XP box.

"(PeteCresswell)" <x@y.Invalid> wrote in
news:inott6p82tmt2d6ircp21ibq5apmmgtge3 (AT) 4ax (DOT) com:

Sounds like a printer issue, since the Citrix session maps the local
printer for you. That could cause any number of issues if the
printer drivers are not in synch. It would also be something that is
client-specific.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

"(PeteCresswell)" <x@y.Invalid> wrote in
news:inott6p82tmt2d6ircp21ibq5apmmgtge3 (AT) 4ax (DOT) com:

I replied before reading this last paragraph. I'd say it's
absolutely the most likely cause of the issue, since mapping the
local printer to the Citrix session is going to make that session
dependent on the configuration of the workstation from which the
session is launched. And printer drivers interact with a huge number
of subsystems, including ALL screen rendering.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

On Thu, 26 May 2011 10:03:34 -0400, "(PeteCresswell)" <x@y.Invalid>
wrote:

I'm wondering if it's some "interesting" reference error where Citrix
doesn't have one of your references but you and most of the users have
the referenced file.

Please run the following code and report the results.

Sub ViewReferenceDetails()

Dim ref As Reference

For Each ref In Access.References
Debug.Print ref.Name & " - " & ref.Major & "." & ref.Minor & "
- " & ref.FullPath
Next ref

End Sub

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

Per Tony Toews:
We ran into that last week with a couple of refs that MS seemed
to have added on it's own... but fixed the problem by removing
them - since they were not used anyhow.

Here's what I'm getting for my own ID right now. Got to wait
until Tuesday to wheedle a password from one of the users that's
having the problem.

References for pCresswell: Development Environment
----------------------------------------
VBA 4.0 C:\Program Files\Common Files\Microsoft
Shared\VBA\VBA6\vbe6.dll
Access 9.0 C:\Program Files\Microsoft
Office\OFFICE11\msacc.olb
ADODB 2.1 C:\Program Files\Common
Files\System\ado\msado21.tlb
DAO 5.0 C:\Program Files\Common Files\Microsoft
Shared\DAO\dao360.dll
Excel 1.5 C:\Program Files\Microsoft
Office\OFFICE11\EXCEL.EXE
Office 2.3 C:\Program Files\Common Files\Microsoft
Shared\office11\mso.dll
MSComctlLib 2.0 C:\WINDOWS\system32\MSCOMCTL.OCX
VBIDE 5.3 C:\Program Files\Common Files\Microsoft
Shared\VBA\VBA6\VBE6EXT.OLB
stdole 2.0 C:\WINDOWS\system32\stdole2.tlb
----------------------------------------


References for pcresswell: Production Environment
----------------------------------------
VBA 4.0 M:\Program Files\Common Files\Microsoft
Shared\VBA\VBA6\VBE6.DLL
Access 9.0 N:\ProgramFiles\Microsoft
Office\OFFICE11\MSACC.OLB
ADODB 2.1 M:\Program Files\Common
Files\System\ado\msado21.tlb
DAO 5.0 M:\Program Files\Common Files\Microsoft
Shared\DAO\dao360.dll
Excel 1.5 N:\ProgramFiles\Microsoft
Office\OFFICE11\EXCEL.EXE
Office 2.3 M:\Program Files\Common Files\Microsoft
Shared\OFFICE11\MSO.DLL
MSComctlLib 2.0 M:\WINDOWS\system32\MSCOMCTL.OCX
VBIDE 5.3 M:\Program Files\Common Files\Microsoft
Shared\VBA\VBA6\VBE6EXT.OLB
stdole 2.0 M:\WINDOWS\system32\stdole2.tlb
----------------------------------------
--
PeteCresswell

"(PeteCresswell)" <x@y.Invalid> wrote in
news:b6r5u61d6h2hc1id2n4v4q2oprvpa790l0 (AT) 4ax (DOT) com:

I would remove all the references I've marked with an asterisk.

In short, I keep my references down to the basic three and use late
binding for everything else.

The reference to the VBIDE is startling to me. Are you automating it
to rewrite code on the fly or something? If so, it sounds like a bad
idea to me.

The MSO.DLL is a completely useless reference, in my opinion, and
MSCOMCTL.OCX is a dangerous dependency (subject to the ActiveX
killbits problem). There is nothing in there that can't be done with
Windows API calls (and SHOULD be done with them). STDOLE2.TLB I'm
not sure about, but it's OLE, so likely not essential. Or, put
another way, there are probably better ways to do things.

So, Excel (which should just be late bound) and ADO aside (ADO
should not be used nearly as much as DAO, so is really not worth the
reference, seems to me), it looks to me like you have a bunch of
legacy references that you should get rid of by removing the legacy
dependencies and migrating the code to use more direct methods, like
Windows API calls.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/