Results 1 to 12 of 12
  1. #1
    Join Date
    Jul 2006
    Posts
    111

    Unanswered: RunCode can't find what it's supposed to run

    I have an Access 2003 application that runs an AutoExec macro. It begins with Hourglass and Echo commands, those work fine. The next two actions are RunCode. These two actions do not work. The first RunCode calls function ReAttach() in module1 in the same .mdb file. The second calls ToolBarShow(False). The error I was getting when I ran my app was "The expression you entered has a functin name that Barden Corporation can't find". I'm not sure where this message originates. Barden Corporation is the name of my customer, it's their code, but I couldn't find any VBA code saying this. I can find ReAttach(), Access cannot. I created a new AutoExec macro without ReAttach() and then got the same error on ToolBarShow() so I deleted that and then it was okay. (But with a toolbar showing, obvioiusly, and without having executed the things ReAttach() does which I don't believe are too terribly important).

    My customer who supports this application from an IT perspective (ie. not a developer's) says when she installs this application on a PC that is also running her company's homegrown software (that interfaces with Access), she gets these errors but on machines without the homegrown s/w there are no errors.

    Isn't this strange? Without getting into what the homegrown app does (I don't think they want me to mess around with it as long as I've come up with a workaround), why would RunCode not be able to find things?

    Oh, and also on my way out of the app, I got an error "Unknown Function Name" and the title in the dialog was Form_Close. (The form did close, and brought me back to my main menu which was what I was trying to do anyway. Then Exit stopped the app cleanly per the norm).

    Please share similar experiences/insights if you have them. Thanks!

  2. #2
    Join Date
    Jul 2006
    Posts
    111
    So far I have found out that it can be a references problem (seems to be the main cause), or the jet engine needs a service pack applied, or I can create a blank database and import everything in and it will mysteriously go away. I will see which one fixes it for me.

  3. #3
    Join Date
    Feb 2004
    Location
    Chicago, IL
    Posts
    1,312
    It sounds to me like the different machines have slightly different version of your referenced libraries. To fix the problem, on the computer that is having the problem, go into the references, uncheck one, then exit. Then go back into references and check the one you unchecked and exit.

    It will probably fix the problem. This just refreshes the references for the specific computer.

  4. #4
    Join Date
    Apr 2004
    Location
    outside the rim
    Posts
    1,011
    hmmmm, welcome to Microshaft.

    From my experience, the probelm (one PC to another, especially with the homegrown wrench) could be references, could also be user permissions (windows level and network level).

    Does the user whose profile underwhich the app is running have read/write to each directory there's data? (this is required for Access even if the app is meant for read only) I've occasionally had issues with user profile setups when working with reference libraries - works for this person, but not that person on the same PC (where all required software was allegedy installed for "all users"). This may be a lead based on the "homegrown" clue - have an Admin log in and try the software.

    Here's another possibility: the odd "build number bug". For details, see This_Post.

    Your most likley candidate, however, is references. It's particularly tricky with different versions of office, but also MDAC, ADO and DAO. Although the office apps are "backwards" and "forwards" compatible in all versions from 2000 forward (according to Microsoft, anyway), your reference libraries will not allow the version to be off by more than 1 and only backwards.

    Here's what I mean. Reference Excel 97 (ver 8) and a machine with Excel 2000 (ver 9) opens the DB. The 2nd machine runs it fine, 1st machine works fine. Then, open it on a machine with Excel XP (ver 11). Access will change the reference to Excel 11 and machine #3 works fine, but now machines 1 and 2 no longer work. No notification is given to the user and this occurs automatically, no matter how the DB is setup.

    The way it plays out is that the code chokes on the first object/function outside the Access module (which is most of them - most common functions are VBA). Comment that out and it will choke on the next function.

    DCKunkle hit the nail on the head for testing it.

    good luck, I hope my long response helps and let us know the solution when you find it!

    tc

  5. #5
    Join Date
    Jul 2006
    Posts
    111
    "Microshaft" - that would be funny if it wasn't so sad!

    I couldn't uncheck the references for VBA or MS 11.0 Object Library because it said it was in use. Is there something I can get out of to "free" these and still be able to access Tools-->References (or is this a Catch 22?) This MUST be the culprit.

    Thanks...I'll be plugging away at this all day so please help if you can.

  6. #6
    Join Date
    Apr 2004
    Location
    outside the rim
    Posts
    1,011
    I couldn't uncheck the references for VBA or MS 11.0 Object Library because it said it was in use.
    You are correct - that is a catch 22.

    To test the references theory, you simply need to change the references. Add a new reference and then compile a module; that will force a refresh.

    Something else I thought of: are the workstations with the "homegrown" using Run-Time or any other versions of Access (I see that you are using Access 2003). Mixing versions with Run-Time installed will cause issues; also, unless you are saving in Access 2K, that could be a problem as well.

    tc

  7. #7
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    Quote Originally Posted by M Mock
    I couldn't uncheck the references for VBA or MS 11.0 Object Library because it said it was in use. Is there something I can get out of to "free" these and still be able to access Tools-->References (or is this a Catch 22?) This MUST be the culprit.
    You could write some code to turn this function off?
    I have written code to turn it on so there must be a way
    A project I was working on a few weeks ago needed MSO library 10.0 or above so I had some nifty error handling to disable the App when that wasn't present.

    So yeah, havn't got the app on the machine I am using at the moment but if needed I can pootle back through my documentation or code to find something that you can use to turn the reference on (as mentioned, have never turned a reference off but it must be just as easy!)

    Alternatively you can use the code I made to check if it is there and add it if it is not.

    - GeorgeV
    George
    Home | Blog

  8. #8
    Join Date
    Jul 2006
    Posts
    111
    *** UPDATE ***

    I hope no one thinks I am ignoring his/her advice. I very much appreciate your attention and replies. But here is the future direction of this app, and what my boss told me I should be doing about the error. In the long term, this app will be converted to VB.NET and SQL Server so my boss told me not to waste time getting it to work since its future as an Access app will be short-lived. I mentioned in a previous reply that I commented out the two RunCode's that are causing the error. Instead of leaving it this way, I want to find an alternative means to implement their functionality.

    1. RunCode runs a function called ReAttach. This function simply does a RefreshLink call on each table that's really a SQL Server linked table, like so:
    Public Function ReAttach()
    Dim tdf As TableDef
    Dim strConnect As String
    Dim rsConfig As Recordset
    Dim strDatabase As String
    Dim strUID As String
    Dim strPassword As String
    Dim strDSN As String

    Set db = CurrentDb()

    Set rsConfig = db.OpenRecordset("Config", dbOpenSnapshot)
    strDatabase = rsConfig!DatabaseName
    strUID = rsConfig!UserID
    strPassword = IIf(IsNull(rsConfig!Password), "", rsConfig!Password)
    strDSN = rsConfig!DSN
    rsConfig.Close

    'strConnect = "ODBC;DATABASE=" & strDatabase
    'strConnect = strConnect & ";UID=" & strUID
    'strConnect = strConnect & ";PWD=" & Trim(strPassword)
    'strConnect = strConnect & ";DSN=" & strDSN & ";"

    strConnect = "ODBC;DSN=" & strDSN
    strConnect = strConnect & ";UID=" & strUID
    strConnect = strConnect & ";PWD=" & Trim(strPassword)
    strConnect = strConnect & ";DATABASE=" & strDatabase & ";"
    'Debug.Print strConnect

    'MsgBox strConnect

    DoCmd.Hourglass True

    For Each tdf In db.TableDefs
    If Len(tdf.Connect) > 0 Then
    tdf.Connect = strConnect
    tdf.RefreshLink
    End If
    Next
    DoCmd.Hourglass False

    'MsgBox "tdf equals nothing"

    Set tdf = Nothing
    Set db = Nothing

    End Function


    Why is RefreshLink even necessary? Or forget the Why..., is RefreshLink even necessary? The help on it says, Updates the connection information for a linked table (Microsoft Jet workspaces only). But I am unclear why connection information needs to be updated. This code is getting called from AutoExec. Why when you are initializing/loading your app do you have to update connection information? Or why at all?

    2. RunCode hides the toolbar. I'm sure I can find a different way of doing this.


    I hate sidestepping the issue, but in this case it may make the most sense.

    Thanks.

  9. #9
    Join Date
    Jul 2006
    Posts
    111
    Instead of having a RunCode command in Autoexec, I am calling the two functions in Form_Load.

    If anyone wants to enlighten me, I am curious about why relinking tables is necessary (or not). I am blindly doing it, because it's always been there and I am able to call it from my Form_Load with no problems.

    Thanks.

  10. #10
    Join Date
    Jul 2006
    Posts
    111
    ...and I mark this [RESOLVED] by doing what?

  11. #11
    Join Date
    Apr 2004
    Location
    outside the rim
    Posts
    1,011
    I haven't specifically worked with SQL Server linked tables, everything I have worked withoutside of Access data sources was VB (Access), ODBC and Paradox.

    In no cases did I ever find I had to perform relinking on a regular basis. I generally relinked when I had to plant a copy of the data source in the user's temp directory because ODBC can be so damn slow over a poorly setup network.

    So, I have to wonder the same why.

    tc

  12. #12
    Join Date
    Jan 2007
    Location
    California, USA
    Posts
    520
    I just inherited an app that was doing this re-linking of SQL Server tables, and it was taking about 2 minutes EVERY time the database was opened. The first thing I did was shut it off, and still have not had any problems. I have no idea where some people come up with their weird ideas of what needs to be done, but the user are VERY happy they don't have to look at that stupid coffee pot pouring coffee into a coffee mug for 2 minutes while the tables are being re-linked.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •