Results 1 to 11 of 11
  1. #1
    Join Date
    Apr 2004
    Location
    outside the rim
    Posts
    1,011

    Unanswered: Pls stop Microshaft from protecting me!

    A puzzler!

    In an attempt to get my department to start standardizing, I created a nifty little component database in Access 2003, set to save in Access 2000 format (so that others could use it). The purpose was to put some fancy bells and whistles in it and to make it very user friendly (if it isn’t easy, they won’t use it).

    Here’s the problem: when anybody else opens it up (no matter the platform or Access version), all code is disabled. If I set a “Start Up” form, the form loads, but no code runs (all events are dead). If I don’t set any “Start Up” options, the same result when they open it and launch any form in it.

    Now, if any of the other users open the DB in bypass and then open the start form, it works just fine! This is true even if I do not set any “Start Up” options.

    I searched through every setting on both ends of this equation and can not come up with an assignable cause.

    Any ideas?

    Thanks!

    tc

  2. #2
    Join Date
    Mar 2005
    Posts
    261
    I'm not 100% sure, but I had a similar issue a while back. Here were my findings:

    Access stores the build number of the current running Access instance in a property of the MDB file when it opens it.

    Code:
    ?CurrentDb.Properties("Build")
    In Access 2003, it misses the first digit, i.e. build 6566 is stored as 566. Not a major problem so far...

    However, Access 2000 checks the Build number of the file when it opens it and seems to put the database into some kind of "compatilibity mode" if the Build number is lower than 2304 (perhaps a beta-compatibility mode since it is based on the Build number).
    In *some* circumstances this causes a problem like the one you described.

    For instance, if you have a text box with the control source set to an expression - e.g. "=Date()" or "=DLookUp(etc)" and this form is the first form to open, then the events on this form will not work if the Build number stored in the database was lower than 2304 when you opened the file. (But usually closing the form and re-opening it automatically fixes the problem).

    It's a really weird bug and difficult to replicate, but I suspect if you override the Build number in a VBA startup routine so that the value is always over (or equal to) 2304, then this might fix your problem (it fixed the problem for me).

    Code:
    Function FnStartup()
     
        CurrentDb.Properties("Build") = 2304
    
    End Function

  3. #3
    Join Date
    May 2004
    Location
    New York State
    Posts
    1,178
    Check your References; make sure they're all in there and with the right priority. When I saved an A2k3 DB in an older format, it wreaked havoc with my references.

    Sam

  4. #4
    Join Date
    Apr 2004
    Location
    outside the rim
    Posts
    1,011
    Good ole Microshaft strikes again!

    You nailed the problem righton the head waynephillips:
    Quote Originally Posted by waynephillips
    However, Access 2000 checks the Build number of the file when it opens it and seems to put the database into some kind of "compatilibity mode" if the Build number is lower than 2304
    The first line of code in the open event of my startup form resets the build property to 2304 and now it works fine in 2K.

    Thanks!

    tc

    PS: Sam - good point as well! 90% of the time, references are to blame for things like this.

  5. #5
    Join Date
    Mar 2005
    Posts
    261
    Good, I thought so. I will add the bug to my site, now that I know I wasn't the only one that had experienced it!

    Wayne Phillips
    http://www.everythingaccess.com

  6. #6
    Join Date
    Apr 2004
    Location
    outside the rim
    Posts
    1,011

    Microshaft strikes again

    ok, so, as shown in the thread, problem was identified and fixed.

    Now, about a month later, the program (no changes) starts crashing in 2K on open - whether opened through the startup, or opened in bypass and then opening the form.

    The cause, you might ask? (rehtorical question):
    Code:
    CurrentDb.Properties("Build") = 2304
    I commented out this line and now it works again in 2K. Today, I open the original source code version in Access 2003 and experience the same crash problem ..... yet yesterday, it was fine.

    So, the question is, what else is going on here?

    PS: now that the "Build" property isn't being reset, it is once again 814.

  7. #7
    Join Date
    Mar 2005
    Posts
    261
    I commented out this line and now it works again in 2K.
    Interesting. is this the only line of code you changed? If your file has become corrupt, then sometimes just changing *any* code in the database can fix the corruption (because it re-writes the compiled code etc). So, how sure are you that this exact line was the cause? (i.e. did you try altering any other code first?)

    If you are sure it was this line, then try increasing the build number. I only suggested 2304 because this is the 'cut off' point for the particular error that you came across. It may be that the build number needs to be higher again to avoid other 'compatibility mode' stuff based on the build number.

    A better recommendation would be to first check if the build number is below 2304, then only if it is, change it to one of the official release build numbers. For example Access 2000 without any Service Pack has build number 2719.

  8. #8
    Join Date
    Apr 2004
    Location
    outside the rim
    Posts
    1,011
    how sure are you that this exact line was the cause
    I stepped through the code, which checks the build number first. It crashed when it got the the line of code shown. I uncommented it and it crashed again, so it was repeatable.

    A better recommendation would be to first check if the build number is below 2304
    I do.

    is this the only line of code you changed?
    actually, yes. Once we got it working on all workstations, I walked away to other projects and only came back when it stopped working. I pulled out a laptop with Acc 2K and tried it out myself and *poof* it reliably crashed every time after working for a month.

    The most puzzling part, though, is that yesterday, it worked on my PC with Acc 2003 and today it crashed ... same solution fixed it. Although, in this case, I uncommented the code and it still works.

    Maybe it's sun spots.

  9. #9
    Join Date
    Mar 2005
    Posts
    261
    I stepped through the code, which checks the build number first. It crashed when it got the the line of code shown. I uncommented it and it crashed again, so it was repeatable.
    That makes it even more weird.

    I have doubts that setting a property such as the "build" one in question here will have any effect until Access specifically checks that property.

    I suspect that the Properties collection has become corrupt in your database - I wonder if you could try changing one of the other CurrentDb properties (or creating a custom one) to test if it is that specific property that is crashing or whether it could be the Properties collection.

    Either way I would change the 2304 number to 2719 as it is less likely to cause further issues (since its an official release build number).

    Does compact & repair or importing everything into a new database fix the issue?

  10. #10
    Join Date
    Feb 2005
    Posts
    333
    I just posted a thread that I am experiencing weird problems in a A2K database. Would the build number be affected if the db was designed in A2K and opened by a user that has A2003? Unfortunately, we now have a hybrid (2k/2003) environment.

  11. #11
    Join Date
    Mar 2005
    Posts
    261
    Quote Originally Posted by campster
    I just posted a thread that I am experiencing weird problems in a A2K database. Would the build number be affected if the db was designed in A2K and opened by a user that has A2003? Unfortunately, we now have a hybrid (2k/2003) environment.
    When you open the database in Acc2003, the build number stored in the database is set to an abnormally low number (due to a minor bug in Acc2003). This doesn't seem to cause any problems for Access 2003, but in some very parculiar circumstances it causes some problems when the file is next opened in Access 2000.

    I've only ever seen this bug cause the 'no event will fire' problem outlined in the first post, and it almost always fixes itself by doing a compact and repair or just closing out and re-opening the database. The build number bug could possibly cause more problems than this, but I haven't seen any evidence as yet.

    I've read your thread - it sounds like corruption rather than this bug. Always a slightly higher risk of problems/corruption in a hybrid environment.

Posting Permissions

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