win 7 + access 2007 runtime => errors

Discussion in 'Microsoft Access' started by Alain Bourgeois, Feb 17, 2011.

  1. Hi,

    I have a continuous form with one field with the following characteristic:
    * controlsource property is a vb function call (e.g.:=getresttext([ID
    Traitement];[DateRDZ])
    * There is a conditional formating on this field, based on an expression
    (true/false)

    This works with any access>= access 2k and any windows >=win '98 (if service
    packs are installed) but win 7 has a trouble with access 2007 runtime (can't
    we buy access 2003 anymore? :( ).
    (I didn't test but wouldn't be surprised if same would occur with full
    version of access 2007).

    But with windows 7 (starter edition, home edition, professional edition),
    the field is shown as blank (value is not shown), and value appears when one
    of the following events occur:
    * move the mouse over the zone, value appears for the zone (so it is a
    real display issue, even not a computation issue),
    * Or click in the zone, value appears for the zone,
    * Or press F9, value appear for all records on the screen.

    Access runtime 2007 on win xp doesn't have any problem with this.

    We had this problem in the past with vista, problem was corrected by
    installing vista service pack 1.
    I applied all win7 patches, nothing is solved.
    We now have the same problem with windows 7... new version, same bugs, it
    seems MicroSoft Office is not in the list of the applications tested when a
    new windows version is sold (Incredible!)

    Does anyone has a solution for this?
    I hope a win 7 patch should solve this, but when?

    Regards,
    Alain
     
    Alain Bourgeois, Feb 17, 2011
    #1
    1. Advertisements

  2. Alain, you can look at sites where old software is sold for Office 2003
    (I've bought and sold used and new non-current versions of software on eBay
    and seems there's another site specializing in old software -- you should be
    able to seek it out by Googling).

    If there are computer "swap meets" around your area, you may also be able to
    obtain older versions, sometimes new in shrinkwrap, there. I went to a swap
    meet in the Dallas, TX area while Office 2000 was current, and found one
    vendor who had still new in shrinkwrap copies of Access 1.0 and Access 2.0
    for sale. But, even more pertinent, another dealer had inexpensive copies
    of Office 97 -- several of my user group colleagues bought those Office 97
    Pro copies, which as far as any of us knows, are genuine. At least one or
    two of them used those copies to qualify for installing upgrades to later
    versions.

    Larry Linson
    Microsoft Office Access MVP
     
    Access Developer, Feb 18, 2011
    #2
    1. Advertisements

  3. I know I can find "second-hand" legal office versions.
    But it would be better for microsoft to correct these bugs.
    It is very strange that problem occur only with the most up-to-date versions
    of microsoft software (office 2007 or 2010 on win 7) and not with previous
    ones.

    If microsoft doesn't correct a such obvious bugs, it really means telling to
    his customers : "go to other software, we don't want to sell office
    anymore".
    MS-Office is a great tool and is not free, the programming environment
    (database, vba, macros, ...) is the difference with open office suite, and
    people agree to pay to get this difference... But if this feature doesn't
    work correctly anymore, then buying microsoft office doesn't have any
    interest anymore.

    If I look at last versions of windows (vista, 7), it seems that everything
    is done to make life difficult to microsoft office programmers!
    Some samples?
    * User account control: if not turned off, a drag & drop of a file is not
    possible from an application to another (e.g. from scansoft paperport to
    access hyperlink field on a form),
    * sandbox mode has to be set to 0 in registry, otherwise a macro cannot call
    a vba function,
    * opening office 2000 ressets office 2007's sandbox mode to 3 (why why
    why?),
    * directories where applications are stored have to be approved,
    * registry key have to be added to avoid a security warning if a user clicks
    a control with a hyperlink property on an access form (occured in access
    2003 also),
    * fields with conditional format don't work with win 7 (and also don't work
    on vista if sp1 is not installed),
    * if computer is win 7-64 bits, mdb has to be compiled with access 2007 to
    be usable by access 2007 runtime (and this is not the case with win 7 32
    bits),
    * ...

    Last but not least, none of these features (implemented "for security
    reasons") will prevent a computer from getting infected by a virus.
    The added value of these things is, according to my experience, 0, null,
    nada... except boring end-users and developers.

    Regards,
    Alain
     
    Alain Bourgeois, Feb 18, 2011
    #3
  4. If you were expecting me to mount a defense for Access 2007 or Access 2010
    (or any particular version of Windows), I hope I'm not disappointing you.

    I acknowledge all these drawbacks and also quote my Access clients who say
    that if they move to a later version than Access 2003, they will have
    re-training expenses, plus a long time of their employees making actions
    "second nature" as they have with Classic Office because of the drastic and
    dramatic change to the user interface with the advent of The Ribbon.

    As my clients do not have needs for me to help them with Access versions
    after 2003, that is the most recent version of Access installed on any of my
    computers. That is why I was trying to be helpful by suggesting sources for
    obtaining "Classic Access".

    Larry Linson
    Microsoft Office Access MVP
     
    Access Developer, Feb 18, 2011
    #4
  5. UAC is a really good thing, as it finally makes setting up all users
    as administrators a safe thing to do. The problem is that after
    Windows was properly locked down, vast numbers of users still
    continued running as admin instead of running as a user-level
    account. Because of that, many software makers never really adapted
    (Intuit, I'm looking at you!), and thus when UAC came along, they
    were caught with their pants down, with software that broke.
    This is not a Win7/Vista issue. It's been that way since at least
    A2003.
    This is not a Win7 issue. It's a decision by MS to be autocratic
    about allowing only one version of Office to be registered at a
    time. It's not an issue for end users, who mostly only have one
    version of any Office app installed at a time, but it's terribly
    inconvenient for developers.

    But it's not a Win7 issue -- it's a result of MS's design of how
    Office works, and it's been this way since Office 2000.
    I don't know what this means, but the fact is that since Windows
    2000, it has been the case that you shouldn't install an Access app
    in the Program Files folder or in the root of the system drive --
    both of those locations have been read-only for non-admin users
    since Win2000. From that time on, the only proper place for
    installing an Access app has been the user profile, and that is BY
    DESIGN. Vista/Win7 FORCE this on you because of UAC, and IT'S A GOOD
    THING. It's long past time for people to stop running their copies
    of Windows in the least secure mode possible.
    Not a Win7 issue -- that's A2003.
    I don't know about this one. Any Knowledge Base articles on it?
    I have always been wary of compiling to MDE in anything but the
    target runtime environment. Indeed, most of my apps are not deployed
    as MDEs at all, because I've just encountered too many problems.
    It's also a lot easier to debug an MDB, and my apps are riddle with
    bugs that need fixing. If I distributed MDEs, it would be much
    harder to identify and fix these bugs (for instance, I could never
    do an instant fix over the phone by telling the user what to type --
    I don't do this often, but occasionally I can get an end user past a
    simple bug by doing that).

    But of course, if MS says you're supposed to be able to do this, you
    should be able to do so.
     
    David-W-Fenton, Feb 20, 2011
    #5
  6. There are three types of things in your list:

    1. UAC (1 & 4)

    2. issues with Office itself (2, 3, 5)

    3. bugs (6, 7)

    Your #4 (locked down folders) have been there since 1999, but only
    Vista/Win7 have forced people to get with the program. If you didn't
    adapt in the Win2000 era, then it is really your problem, and I have
    no sympathy whatsoever when you are forced to fix your erroneous
    practices in order that they work with UAC. Perhaps you should read
    this:

    http://en.wikipedia.org/wiki/Principle_of_least_privilege

    Your #1 is just a complaint about applications that have not been
    updated to account for UAC. This is not the fault of Microsoft or of
    Windows, but of the makers of the software for not updating to keep
    up, or your own fault for not acquiring a version of the software
    that is compatible with the OS you're running.

    Both of these things are definitely helps for preventing the running
    of nefarious code, i.e., viruses, trojans and worms. The main reason
    that most exploits now come through email and the browser is
    precisely because these changes in the OS security have prevented
    most of the old ones from propagating well (because they required
    permissions that they no longer are able to elevate to easily).

    The Office issues are not new at all. The dueling registrations have
    been a problem since Office 2000 (though that was actually solvable
    when the fight was with Office 97, since the O97 registration files
    were editable in a way that would cause things to remain stable).

    I would agree that #2 and #5 are ineffectual, but I don't think they
    are so much aimed at stopping viruse, etc. (which don't actually
    exist in Access) but in allowing corporate IT shops from preventing
    the running of unauthorized code. This is not in the interests of
    Access developers at all, of course, and doesn't help end users. But
    those two consistuencies don't have MS's ear to the extent that big
    corporate IT departments do. But it's also the case that these
    issues have been there for well over 5 years, so why you'd be
    complaining about them now, I can't say.

    The last two on your list are just bugs so far as I can tell, so not
    relevant to AV or Win7 at all.

    Looks like a real mixed bag to me. Your criticisms don't seem
    coherent, nor relevant to the specific topic (A2007 runtime and
    Win7), though this may be the first time you've encountered them in
    a live project.
     
    David-W-Fenton, Feb 20, 2011
    #6
  7. Concerning UAC:
    1. Most users are administrator of their computer (they own it, no?).
    2. They work in workgroup and write documents to a shared folder, and
    work with a shared database.
    -> I can agree that if you give a dummy the right to install viruses they
    will be able to do it. Here: users are professionnals that use applications,
    even not connected to the internet... so the risk to get a virus is 0.
    -> I would agree with you if such "security things" would prevent users to
    get spywares/viruses. I can show you lots of computers where these "security
    things" didn't solve anything

    Concerning office issues: in access<=2003, tools / security / low. Easy to
    fix.
    However, I can live with these 2 issues. Most important problem is bugs. And
    bugs # 6 is related to win 7, as it doesn't occur on other windows versions
    with the same access version.

    But however, I don't dare to think to all reg keys we will have to add in
    access 2015... But perhaps in 2015 I will have brought my office
    applications to Apple (seriously thinking about it).
     
    Alain Bourgeois, Feb 21, 2011
    #7
  8. They shouldn't be RUNNING as administrator (unless they have
    Vista/Win7, in which case, they can log on as admin and by default,
    all processes will run with a user-level security token, unless
    you've overridden the default).

    They should be running with user-level permissions when they are
    working as a user. They should only be running as admin when they
    are performing administrative functions.

    This is pretty basic. It's the way Linux works (SUDO) and it's the
    way Mac OS X works. It's the way Windows always should have worked,
    but it was only properly implemented beginning with Windows 2000
    (when proper permissions were applied that made system areas
    read-only for user-level logons) and finally properly implemented in
    Vista (though with UAC defaults set so that it was noisy and
    annoying; Win7 fixed that problem so that UAC is now pretty much not
    seen unless you're really doing something that requires admin
    permission).

    Did you read the Wikipedia article I cited? It explains the
    principle of running with the least privileges:

    http://en.wikipedia.org/wiki/Principle_of_least_privilege

    When you run with excess privileges, you risk delegating too much
    authority to processes that don't need it, including nefarious ones.
    So, a peer-to-peer network with no domain controller. In that case
    you can use the EVERYONE group on the "server" so that shared
    documents are available to everyone without user authentication.
    This is not my preferred environment, but it's OK. It's also the
    default for shares in that environment, so shouldn't be an issue.
    By running as admin, you are doing just that.
    No, it's absolutely NOT zero.

    And UAC under Win7 is fine. It's not bothersome and it interferes
    with almost nothing. If you have software than can't function under
    UAC, then you need to get a software update for Vista/Win7, because
    it's badly-designed software. Any software designed to run under
    Windows 2000 or later with a user-level logon should have NO
    problems running under UAC. Any software that DOES have problems
    under UAC is actually more than ten years out of date in its design
    (e.g., QuickBooks).
    They can still get user-level infections, yes, but that's much less
    of a risk to the software ecosystem than if they ran as admin.
    It may be "related" to Win7 (I think it's more a 64-bit issue than a
    Win7 issue), but it's not a Win7 bug -- it's something that ought to
    be fixed in Access, but it won't because A2003 is old.
    If you'd keep up with proper user configurations and not insist on
    running under rules that went out the window in 1999, you'd have a
    LOT fewer problems.
     
    David-W-Fenton, Feb 23, 2011
    #8
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.