none
Environ("Username") as Criteria in a Query Object

    Question

  • I can use Environ("Username") in code .. no problem.  But a problem arises when using Environ("Username") in the criteria of a query object.  In Access97 I could user a query object whose SQL read:

    SELECT tblActivity.*  FROM tblActivity WHERE tblActivity.UserID)=Environ("Username"));

    Now in Access2007 I get an error saying:

    "Undefined function 'Environ' in expression"

    So ... what is a substitute for Environ("Username")?  The answer is NOT CurrentUser() as that will reply 'ADMIN' .... I need the user's network login ID which is what Environ("Username") generates.

    Suggestions?

    Wednesday, December 22, 2010 3:33 PM

Answers

  • Jane Hancock wrote:

    I can use Environ("Username") in code .. no problem. But a problem
    arises when using Environ("Username") in the criteria of a query
    object. In Access97 I could user a query object whose SQL read:

    SELECT tblActivity.* FROM tblActivity WHERE
    tblActivity.UserID)=Environ("Username"));

    Your parentheses are not correct (1:3 for the rights)
    but I assume that you've trimmed the SQL statement.

    Now in Access2007 I get an error saying:

    "Undefined function 'Environ' in expression"
    ...

    I use API functions instead of Environ(). When you e.g. copy
    Dev's code from http://www.mvps.org/access/api/api0008.htm
    into a standard module, you could use

    WHERE tblActivity.UserID=fOSUserName()

    That having said Environ should work too, but maybe it's blocked
    by sandbox mode. To overcome this you could either create your
    own function "Environ" in a standard module to overwrite the
    original function or you could change the registry to disable
    sandbox mode. The registry key depends on your Win version:
    http://social.answers.microsoft.com/Forums/en-US/addbuz/thread/ba3ffb81-d2d0-4c74-b966-b6893e9bd539


    cu
    Karl
    *********
    Access-FAQ (German/Italian): http://www.donkarl.com

    • Marked as answer by Jane Hancock Monday, December 27, 2010 3:42 PM
    Wednesday, December 22, 2010 4:15 PM
  • I always cringe when I see anyone relying on the value of the Username environment variable, given how easy it is to change the values of environment variables.

    Use the GetUserName API call (as illustrated in http://www.mvps.org/access/api/api0008.htm at "The Access Web") instead.

    (Note: this will not work if you're trying to run the query from outside of Access)


    Doug Steele, Microsoft Access MVP
    http://www.AccessMVP.com/djsteele (no e-mails, please!)
    • Marked as answer by Jane Hancock Monday, December 27, 2010 3:42 PM
    Wednesday, December 22, 2010 9:13 PM

All replies

  • Jane Hancock wrote:

    I can use Environ("Username") in code .. no problem. But a problem
    arises when using Environ("Username") in the criteria of a query
    object. In Access97 I could user a query object whose SQL read:

    SELECT tblActivity.* FROM tblActivity WHERE
    tblActivity.UserID)=Environ("Username"));

    Your parentheses are not correct (1:3 for the rights)
    but I assume that you've trimmed the SQL statement.

    Now in Access2007 I get an error saying:

    "Undefined function 'Environ' in expression"
    ...

    I use API functions instead of Environ(). When you e.g. copy
    Dev's code from http://www.mvps.org/access/api/api0008.htm
    into a standard module, you could use

    WHERE tblActivity.UserID=fOSUserName()

    That having said Environ should work too, but maybe it's blocked
    by sandbox mode. To overcome this you could either create your
    own function "Environ" in a standard module to overwrite the
    original function or you could change the registry to disable
    sandbox mode. The registry key depends on your Win version:
    http://social.answers.microsoft.com/Forums/en-US/addbuz/thread/ba3ffb81-d2d0-4c74-b966-b6893e9bd539


    cu
    Karl
    *********
    Access-FAQ (German/Italian): http://www.donkarl.com

    • Marked as answer by Jane Hancock Monday, December 27, 2010 3:42 PM
    Wednesday, December 22, 2010 4:15 PM
  • Hi Jane,

    I often use it in A2003 any ways (code, queries) and it's ok. I've just check your issue in A2007 and have faced the same problem. So it would be interesting for me too to hear the reason for it.


    Andrey V Artemyev | Saint-Petersburg, Russia
    Wednesday, December 22, 2010 8:17 PM
  • I always cringe when I see anyone relying on the value of the Username environment variable, given how easy it is to change the values of environment variables.

    Use the GetUserName API call (as illustrated in http://www.mvps.org/access/api/api0008.htm at "The Access Web") instead.

    (Note: this will not work if you're trying to run the query from outside of Access)


    Doug Steele, Microsoft Access MVP
    http://www.AccessMVP.com/djsteele (no e-mails, please!)
    • Marked as answer by Jane Hancock Monday, December 27, 2010 3:42 PM
    Wednesday, December 22, 2010 9:13 PM
  • Hi Andrey
    The reason is probably the enhanced Security of Access 2007 or the operating system it's running on. It doesn't allow anymore just to access anything in the system without proper permissions.
    As you allow VBA code to run you may do following.
    In a standard Modul place this code:
     
    Public Function Environ(Expression As String) As Variant
      Environ = VBA.Interaction.Environ(Expression)
    End Function
     
    Now you have a UDF with the same name. The precedences should now ensure you will run the UDF before you run the the original Environ() method that is defined in the VBA.Interaction class.
    As you allow VBA to access this class, but queries aren't allowed to, the query now get's the result from VBA instead of it builtin expression service (similar to VBA, but not exactly the same). This way you bypass the Jet security and base on VBA security, which is more open as you've seen.
     
    As you give the UDF the same name you shouldn't have to change any other code in your application. Maybe you have to place some error handling in the function itself.
     
    HTH
    Henry

    Hi Jane,

    I often use it in A2003 any ways (code, queries) and it's ok. I've just check your issue in A2007 and have faced the same problem. So it would be interesting for me too to hear the reason for it.


    Andrey V Artemyev | Saint-Petersburg, Russia
    Thursday, December 23, 2010 4:05 AM
  • Henry,

    thanks for your explanation! Just for interest I'll try it later reaching the PC with A2007. :)

    Doug,

    in my case there are a lot of circumstances not to be worry about it. Even the command line itself isn't accessible in our company for mere mortals. But let me ask one question. If I change env.string is it necessary to launch Access from the command line to see changes?


    Andrey V Artemyev | Saint-Petersburg, Russia
    Thursday, December 23, 2010 6:36 AM
  • Hi Doug

    I'm not sure if this is still possible. It was possible to fake the "UserName" environment variable in earlier Windows Versions (Win95, for example) by opening a Command Window and seting the UserName variable to another value, for example by typing:

    C:>\SET UserName="SomebodyElse"

    and then start Access from the command line within the same command prompt window. If you then used Environ("UserName") you got "SomebodyElse" instead of your logged in Username.

    I just tried it again under Windows XP and I will not get the faked UserName, when I call Environ() in Access started in the "faked" environment.

    BTW: This fact was the main reason why the use of the FileSystemObject or some API calls have been propagated to read the real UserName. In a secure environment the User shouldn't have the permission to change the UserName environment variable or opening a command prompt. In such environments the simplier approach is IMO acceptable. And as a secure envirionment I'd only accept currently maintained Windows versions, this means Windows Vista ff, and Windows Server 2008 ff. and with some exceptions Windows XP. If it doesn't work in WinXP anymore, I'd expect it doesn't in Vista ff and Server 2008 ff either.

    Annotation: By encapsulating the Environ() function as I mentioned above you have a simple possibility to use a Case statement to switch it on a single place. You also may add other Envirionment Variables you don't want the user will be able to fake..

    Public Function Environ(Expression as String) As Variant
      Select Case Expression
        Case "UserName"
          Environ = .. 'do your API call here
        Case Else
          Environ = VBA.Interaction.Environ(Expression)
      End Select
    End Function

    Thursday, December 23, 2010 7:12 AM
  • Hmm. Looks as though you're right Henry, at least with Win7. However, I'm sure I've done it successfully using WinXP, since that's what I was using at work until recently. If I have time, I'll try testing on an XP machine later today.

    I'm wondering, though, whether it wouldn't make more sense to use a different function name, rather than overriding the VBA function.


    Doug Steele, Microsoft Access MVP
    http://www.AccessMVP.com/djsteele (no e-mails, please!)
    Thursday, December 23, 2010 1:05 PM
  • Hi Doug
     
    I'd use a different function name if this wouldn't be an existing application.
     
    I share the same "scary" feeling when overtyping built-in VBA functions;-) I wouldn't recomend it if I wouldn be  pretty sure it works. Just see what happened for the OP with the two different implementations in Jet and VBA: One works the other doesn't. App broken. It can not become worse doing the overtyping. If I force Jet to use the VBA function, it will work the same way in both envirionments. Either it breaks in both or it works.
     
    Another place I use this is the MsgBox() function. I overtype it since many years (since they decided to depreciate it) and never ever had a problem doing so. This way I still can use the old message boxes in new applications where you have the 3 sections seperated by @.
     
    Henry
     

    I'm wondering, though, whether it wouldn't make more sense to use a different function name, rather than overriding the VBA function.

    Friday, December 24, 2010 4:10 AM
  • Douglas J Steele [MVP] wrote:

    Hmm. Looks as though you're right Henry, at least with Win7. However, I'm sure I've done it successfully using WinXP, since that's what I was using at work until recently.

    I tested it a few months ago in Win XP when a particularly obnoxious
    poster questioned my pontifications.  <smile>

    Now personally I don't feel it should've been fixed in Vista or Windows
    7.    I'd use that as a credibility check.  If they're different I'd
    have metaphoric alarm bells ringing and have folks check that user for
    fraudulant ativities.   <smile>  
    Hmm, I'd have every user, including the fraudster, get a message -45823
    or similar obscure error number and a cryptic message, such as
    "undefined error", pop up on their screen and a note to talk to the
    developer.  As soon as they clicked Ok it would disappear.  Hopefully
    within a day or two someone would tell the dev who would then start
    checking various database log tables.

    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/

    Monday, December 27, 2010 5:03 AM
  • I've just faced this issue with A2003. I have a bunch of old queries where I use Environ("USERNAME") as a criteria. Suddenly (!) they stop working with the error "Undefined function 'Environ' in expression".

    I know the workaround, I know Environ is not the best choice, I will rewrite this part of application later, I just want to know the reason for this suddenness?


    Andrey V Artemyev | Saint-Petersburg, Russia
    Russian blog artemyev.biztoolbox.ru
    English blog enblog.biztoolbox.ru
    Wednesday, September 07, 2011 8:34 AM
  • Hi Andrey

    It can not happen that a function "suddenly" isn't defined anymore or can't be called anymore. The only reason why you could get this message is that VBA, JET or the Expression Service of Access can't resolve the function anymore.

    The reason in all cases where I've seen this behaviour, was that a reference was broken. As VBA, JET and the Expression Service have to resolve the function these need a precedence of the library and references. The own references are coming after the references you add or the code you add. This way you have the possiblility to "overtype" a built in function like the MsgBox() by your own MsgBox(). Instead of displaying the builtin MsgBox() then your MsgBox() will be resolved as MsgBox() if you call it in your code.

    When Access tries to resolve the function it stops further resolving as soon as it finds a broken reference in the references chain. If the builtin Environ() function would be resolved after your broken reference Access wil not resolve it and will trow above menioned error.

    How to fix it:

    - check that all your references can be resolved. You may check the isBroken property of all references in the References collection.
    - If everything is ok, remove one reference you need and close the VBA references dialog. Then reopen it and add the reference again. It's important you close it between.
    - I hardly recommend after this action to do a /Decompile to get rid of all your bytecode and compiled queries
    - Then recompile the application and try again. If the compilation runs without an error you shouldn't see the mentioned error anymore.

    HTH

    Henry

    Wednesday, September 07, 2011 9:39 AM
  • Hi Henry,

    thanks for explanation. However, smth strange for me. It's my dev file, so there are a lot of references for IntelliSense purpose.

    I use this little routine to test .IsBroken property

    Public Sub br()
    Dim ref As Reference
        For Each ref In Application.References
            Debug.Print ref.name & "---" & ref.IsBroken
        Next
    End Sub
    

    And the result is:

    br
    VBA---False
    Access---False
    ADODB---False
    Scripting---False
    Domino---False
    MSForms---False
    Excel---False
    ActiveDs---False
    Office---False
    Shell32---False
    MSComctlLib---False
    DAO---False
    stdole---False

    I can't remove VBA, Access, MSForms references due to the message "Can't remove control or reference; in use". Other references seem to do not affect this behaviour, still the same error. C&R doesn't help. Decompilation doesn't make any difference.

    BTW, I have no access to the Command Line, so I create a .bat file with the following text:

    start "C:\Program Files\Microsoft Office\Office11\MSACESS.EXE" "the_path_to_my_dev_file.mdb" /decompile

    Do I miss anything?


     


    Andrey V Artemyev | Saint-Petersburg, Russia
    Russian blog artemyev.biztoolbox.ru
    English blog enblog.biztoolbox.ru
    Wednesday, September 07, 2011 10:18 AM
  • Hi Andrey

    There is absolutly no reason during runtime to have the references in I can see here. In all my applications I only have VBA, Access and DAO as references set. Everything else is late bound without references and this prevents such an error you see now.

    I understand that for development it's handy to have intellisence active. But this doesn't mean it should be in for the runtime later. I add sometimes such references, too, but as soon as I have finished developping I remove these and replace those by late bindings.

    One reference you have in is know to give troubles some times. Its the MSComctlLib. There are a lot of replacements for the common controls without this library. You better should replace it by some of these modules.

    Why you need ADODB and DAO at the same time? I expect you are running an MDB and are using DAO as standard access technique, true? Then you should be able to remove ADODB or replace it by late binding easily.

    I don't know all references you are using and for what these are. Try to get rid of these and you will have a much more stable application. A single unregistered or replaced DLL else will make such error happens again and again. With late binding the errors then only occur, when you really try to access something in this libraries and the time to load the application is much faster as Access doesn't have first to completely load and build up the object model from all references for your application to resolve it later, even when it will not need it.

    How to start: First get rid of MSCoimctlLib. If you can't check on other systems if these have other DLLs. Re-Register the DLL of this reference and try again.

    HTH

    Henry

    Wednesday, September 07, 2011 11:02 AM
  • There is absolutly no reason during runtime to have the references in I can see here. In all my applications I only have VBA, Access and DAO as references set. Everything else is late bound without references and this prevents such an error you see now.

    I understand and frankly in production .mde there are not so many of them.

    Why you need ADODB and DAO at the same time? I expect you are running an MDB and are using DAO as standard access technique, true? Then you should be able to remove ADODB or replace it by late binding easily.

    I don't, it seems I added ADO reference once to make an example for somebody from this forum, I don't remember. :) At my workplace I always have my dev file open, so sometimes I write code samples here. But I remove them before distribution, of course.

    Finally, I can stay with

    VBA---C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6.DLL---False
    Access---C:\Program Files\Microsoft Office\OFFICE11\MSACC.OLB---False
    Domino---C:\program files\lotus notes\domobj.tlb---False
    MSForms---C:\WINDOWS\system32\FM20.DLL---False
    Office---C:\Program Files\Common Files\Microsoft Shared\OFFICE11\MSO.DLL---False
    DAO---C:\Program Files\Common Files\Microsoft Shared\DAO\dao360.dll---False
    stdole---C:\WINDOWS\system32\stdole2.tlb---False
    Excel---C:\Program Files\Microsoft Office\OFFICE11\EXCEL.EXE---False
    

    Domino - it is Lotus Notes Library I use for e-mail automation purpose because we don't use Outlook (unfortunately). I remove it and Excel references later, it requires some time to rewrite a code.

    But it seems that my decompilation doesn't work. After running this .bat file my dev file is opened but Compile in VBE menu is inactive, like it is already compiled. Should it be so?


    Andrey V Artemyev | Saint-Petersburg, Russia
    Russian blog artemyev.biztoolbox.ru
    English blog enblog.biztoolbox.ru
    Wednesday, September 07, 2011 12:14 PM
  • I have no problem changing the value of the UserName environmental version using Access 2007 in Windows 7. Access should not be open when the value of the variable is changed from the command prompt, and should be opened from the same command prompt. Fiddly, but ludicrously simple for a moderately knowledgeable meddler.
    Ken Sheridan, Stafford, England
    Wednesday, September 07, 2011 12:32 PM
  • Hi Andrey

    If you do a /decompile the compile command should be active, else the /decompile didn't run. The database after the /decompile isn't compiled.

    To your references:

    Domino: I know it's Lotus. If you don't do a lot with it, replace with late binding
    MSForms: Why do you need it. Do you really use MSForms within Access? If so, replace these by Access forms and get rid of this reference
    Office: This reference shouldn't be needed at all. It sometimes is added automatically when you use something like a FileDialog, but can be removed.£
    DAO: after VBA and Access the most important one. Move it up to the 3rd rank
    stdole: never used or seen this. What is it for? If not used at many different places replace it by late binding
    Excel: I got easily rid of Office references (Word, Outlook, Excel, PowerPoint and what ever) and use happily only late binding with those. I don't even mind I don't have intellisense as I always can kick on the Office app directly, open the VBE in there and write my code in a module. If I need help for the object model (another reason for the early binding approach) again: I start the VBE in the app itself and go to it's help. Since I did this my Access app is starting much faster and is running even then when the user don't have this apps installed. It just gives an error if it is really used.

    So if you can do this, you should end up with following references:

    - VBA
    - Access
    - DAO
    - (Domino)

    You will - I'm pretty sure - not want to swich back to early binding when you once used late binding. It's just the more "secure" (or stabler and faster) approach during runtime.

    Thursday, September 08, 2011 2:18 AM
  • Hi Henry,

    I've finally got rid of almost all the references. I always thought it should take me a lot of time, but in fact this amount was ~15 min long.

    BUT! I'm also wondered about this MSForms reference. I can't remove it because of message I described above (reference or control is in use) even if I open a file and don't run any form.

    stdole was OLE Automation, I just removed it w/o problems.

    And a /decompile question still interesting, I can't make it work. If you have no guess about decompile I'll create a separate thread.

    But the Environ error's still alive.


    Andrey V Artemyev | Saint-Petersburg, Russia
    Russian blog artemyev.biztoolbox.ru
    English blog enblog.biztoolbox.ru
    Thursday, September 08, 2011 6:26 AM
  • Sounds great.

    Did you get rid of Domino, too?

    About the MSForms reference: Do you have any tools installed in Access, developpers or Access tools? Maybe these need the reference. But if, these are not good tools.

    Maybe this also prevents /Decompile to run correctly. (Please open a new thread for it, I don't see why it shouldn't work if you are not using a workgroup file, else also add this one and the user/password to the command line. I for myself always use a link on the desktop to do the decompile. Maybe this would be an option for you, too, instead a CMD file that may not get enough permissions to run Access correctly.

    Now to your MSForms Reference:
    To be honest: I never used MSForms in Access yet, only once in Excel. If you don't have anything installed that is forcing to have this reference inside and don't use MSForms somewhere in your application (maybe an activeX in a Form or Report could require it? Or some strange construction in a query calling an MSForm?) you can go the hard way:

    Create an new MDB, set the references exactly how you want to have it (without MSForms). If the new MDB already has this in, then your Access may require some more attention to get rid of it, maybe a new installation.
    Then import all Objects into the new MDB. Don't forget the ImportExport Specifications, Commandbars and what ever you may have defined not visible in the database container.

    Then start the application and try to compile it. It can in no way be compiled when you open it, so the compile action should be active. Now you should see where the problems occurs. It could be exactly this MSForms-Reference that is preventing Environ() to be found.

    And please check also in older version of your app, if the error occours there, too. Maybe you will find the reason then.

    Good luck, I don't know anything else I could wish you.

    Henry

    Thursday, September 08, 2011 6:55 AM
  • According to the last result even luck doesn't help. :)

    So, Domino - yes. The only changed thing there was Set Session = CreateObject("Notes.NotesSession"). And 2 constants. Really a little piece of changes. Generally, I created a separate module and put all the constants there (Excel, Domino and Office). Office Reference was there because of dynamically created menu (CommandBar objects), moving it to Late Binding was also a very simple task.

    MSForms was, as I understand, kinda a bug. I created a blank database, set 3 references only (BTW, by default there were 5: ADO 2.1 + OLE Automation). Then I imported all the forms, tables, queries, reports and modules. Compiled it w/o errors! All seemed to be great, BUT! The same error trying to run a query or a form which use this query for getting some data.

    However, really thanks for importing advise, it reduced my app size from 8 MB to 5MB. :)


    Andrey V Artemyev | Saint-Petersburg, Russia
    Russian blog artemyev.biztoolbox.ru
    English blog enblog.biztoolbox.ru
    Thursday, September 08, 2011 9:19 AM
  • Hot news:

    I sent this file to my colleague. He has almost the same system but he has also Office 2010 installed but w/o Access. So, I have full O2003, he has full O2003 + W2010 + E2010 + P2010. But I don't think it does matter.

    And he has no such an error with Environ! Completely puzzled.


    Andrey V Artemyev | Saint-Petersburg, Russia
    Russian blog artemyev.biztoolbox.ru
    English blog enblog.biztoolbox.ru
    Thursday, September 08, 2011 12:27 PM
  • Decompilation haven't done the trick, still the same error.
    Andrey V Artemyev | Saint-Petersburg, Russia
    Russian blog artemyev.biztoolbox.ru
    English blog enblog.biztoolbox.ru
    Thursday, September 08, 2011 1:58 PM
  • Hallo Henry,

    Henry Habermacher wrote:

    Office: This reference shouldn't be needed at all. It sometimes is added
    automatically when you use something like a FileDialog, but can be
    removed.

    It is required in case you need to handle Ribbon callbacks.


    Peter Doering [MVP Access]

    Thursday, September 08, 2011 4:18 PM
  • It is required in case you need to handle Ribbon callbacks.

    As well as CommandBars in earlier versions.

    However, Late Binding is possible in both cases. In A2003 and earlier I'm sure. In case of Ribbon UI, it seems to be so. I've just tested replacing all the IRibbonControl and IRibbonUI with Object and removing the reference. Right now I can't see any issues with this.


    Andrey V Artemyev | Saint-Petersburg, Russia
    Russian blog artemyev.biztoolbox.ru
    English blog enblog.biztoolbox.ru
    Thursday, September 08, 2011 4:58 PM
  • Andrey Artemyev wrote:

    It is required in case you need to handle Ribbon callbacks.

    As well as CommandBars in earlier versions.

    However, Late Binding is possible in both cases. In A2003 and earlier
    I'm sure. In case of Ribbon UI, it seems to be so. I've just tested
    replacing all the IRibbonControl and IRibbonUI with Object and removing
    the reference. Right now I can't see any issues with this.

    Neither can I, although I never tested late binding on that. Anyway, I just
    wanted to add clarification to Henry's comment re. MSO.DLL, as since
    introduction of Ribbons the use of this library has increased a lot.


    Peter Doering [MVP Access]

    Thursday, September 08, 2011 9:22 PM
  • Agreed. I don't think this Office reference should cause any problems, just wanted to make a test of late binding here. 
    Andrey V Artemyev | Saint-Petersburg, Russia
    Russian blog artemyev.biztoolbox.ru
    English blog enblog.biztoolbox.ru
    Thursday, September 08, 2011 9:30 PM
  • Hello Andrey,

    Andrey Artemyev wrote:

    It is required in case you need to handle Ribbon callbacks.

    As well as CommandBars in earlier versions.

    However, Late Binding is possible in both cases. In A2003 and
    earlier I'm sure. In case of Ribbon UI, it seems to be so. I've
    just tested replacing all the IRibbonControl and IRibbonUI with
    Object and removing the reference. Right now I can't see any issues
    with this.

    You can use Late Binding only in A2010 in A2007 you need the office
    reference.

    HTH
    Gunter


    Access FAQ: http://www.donkarl.com

          http://www.avenius.com - http://www.AccessRibbon.com
    http://www.ribboncreator.com - http://www.ribboncreator2010.com

    Friday, September 09, 2011 10:56 AM
  • Hi Gunter,

    thanks, it makes sense, I tested exactly with A2010.


    Andrey V Artemyev | Saint-Petersburg, Russia
    Russian blog artemyev.biztoolbox.ru
    English blog enblog.biztoolbox.ru
    Friday, September 09, 2011 11:54 AM
  • The application you are attempting to use has a reference that it cannot resolve to an object, type library, DLL, or external database.  Either the object, type library, DLL, or database was deleted or renamed. Examine the Available references list in the References dialog box in the Visual Basic Editor ( Tools menu) to determine if any action is required. If you did not create this application, contact the programmer or administrator of the system.
    If the reference listed in the Available references list is preceded with "MISSING:" clear the check box to remove the reference if it is no longer required. If you still need to use the reference, clear the check box entry for "MISSING: <referencename>" in the Available references list, and then create a new reference to the file using the Browse... button. If this is an installed database application, you may need to reinstall or repair the application.

    In the library delete "MISSING: <referencename>"

    • Proposed as answer by Nathakb Wednesday, January 02, 2013 10:20 PM
    Wednesday, January 02, 2013 10:20 PM