locked
Access 2003 incompatible with Server 2012 RRS feed

  • Question

  • We have an old Visual Basic 6.0 program that runs on an MS Access 2000 database.  A few months ago we migrated to a new Windows Server 2012.  Subsequently our program began running slower and slower until it was no longer useable.  At that time I researched the problem and found a fair amount of information which indicated that Server 2012 will not adequately maintain Access 2003 and earlier databases.  The workaround was to move the database to an older machine.

    We are now looking into upgrading our program for a more permanent solution and I cannot find information that describes the basic problem.  I am bewildered that a search that yielded plentiful information a few months ago now yields only dribbles and hints of information.  Can anyone point me to a good clear description of the incompatibility between Access 2003 and Windows 2012?

    More to the point, can anyone point me to a good description of the solution?  Do we have to upgrade to Access 2007 and use ADO, or can we run our Access 2003 database using the ACE engine and avoid revising a lot of DAO code?  Would using a different engine solve the problem of Server 2012 not maintaining the database, or must we upgrade to Access 2007 if we want to house the database on Server 2012?  Any information would be appreciated.  Or suggestions for search strings.  I am driving myself nuts searching and searching and not coming up with anything very helpful.


    LouatMonaco

    Wednesday, January 21, 2015 11:04 PM

Answers

  • Ok, that “slow” open is often seen and posted in many forums. As noted, you want to create a persistent connection in the client application. This in “most” cases eliminates that VERY slow opening delay. And this “slow” issue does not appear on all setups – but tends to rear it ugly head on newer computers and networks.

    So in the VB6 application, you want to open a global recordset at startup - and keep it open at all times - do not close that recordset.

     It can be any table in the back end mdb file.

    So not all hope here is lost - this one small change could well fix this. And often really slow opening can be virus and security software that grabs and holds the file - so test that issue also.

    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada


    • Edited by Albert D. Kallal Thursday, January 22, 2015 11:57 PM
    • Marked as answer by Caillen Tuesday, February 3, 2015 2:40 PM
    Thursday, January 22, 2015 11:57 PM

All replies

  • VB6, that was 1998. We are now in 2015. Certainly you have recouped your investment by now, and saved your pennies to rewrite the application using modern development tools. This may be Access 2013 front-end with SQL Server Express Edition back-end, or any number of other combinations. It would require some analysis time to figure out the best configuration for your situation.

    Do not use ADO.


    -Tom. Microsoft Access MVP

    Thursday, January 22, 2015 4:17 AM
  • As several pointed out Access 2000 is 14 years old. I suspect your company is not using ANY other software so old.

    However, having stated the above, it not at all clear why the slow down is occurring. Are the file sizes bloating unnecessary in size? (turn off row locking in Access will often fix this issue).

    So at this point, it not really a given that the software is slowing down due to compatibility issues, but simply that settings used in JET are different then the previous setup you had.

    However, I would certainly consider trying to use the replacement for JET (ACE), and see if that works better.

    I not seen any other articles or issues that point out specific issues with server 2012 + Access 2000. As noted, that is some rather old software.

    I assume that compact and repair is regular done on the database. And “slower and slower” is not much of a technical term.

    And it not clear of only one program is attaching to the database, or there are multiple users (if multiple users, then a persistent connection from VB6 to the database could very well fix this issue).

    You want to test/check out a few of the above issues (C+R, persistent connection, row locking). The reason “why” you need to do the above is upgrading to say Access 2010 would suffer from the SAME reasons and issues. Thus an upgrade will not help until such time you determine if this is a “legacy” issue of running old software, or that your new setup has some issues that can be and need to be resolved.

    So it not clear if the application is multi-user. If yes, then a persistent connection would be the first issue to look at.

    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Thursday, January 22, 2015 8:04 PM
  • Thanks for your suggestions.  "Slower and slower" is vague I agree.  Here is what I mean.  Yesterday I tested the software with a test version of the Access 2000 database on the Server 2012.  It took 15 to 20 minutes to open the application, select one record, and display it.  And that is of course with only one user, and only two records in the database.

    We are in a multiuser situation (10 users max and very light use per user), but in many years of use have not had this problem. 

    I failed to describe the issue accurately.  We are working on an upgrade to VB.net, database as yet undecided but it will be something modern. :-)  We are a very small company so the timeline for the upgrade stretches out far into the future.  We are trying to determine if we can do some sort of interim quick fix to our existing VB6 application and our old Access 2000 databases so that our users don't have to cobble together a connection across two servers.  Cost-benefit analysis about describes it.

    We are having trouble figuring out what would be involved in a modest interim upgrade.  Perhaps our technology is so old that the relevant information has been archived and forgotten.


    LouatMonaco

    Thursday, January 22, 2015 9:03 PM
  • Ok, that “slow” open is often seen and posted in many forums. As noted, you want to create a persistent connection in the client application. This in “most” cases eliminates that VERY slow opening delay. And this “slow” issue does not appear on all setups – but tends to rear it ugly head on newer computers and networks.

    So in the VB6 application, you want to open a global recordset at startup - and keep it open at all times - do not close that recordset.

     It can be any table in the back end mdb file.

    So not all hope here is lost - this one small change could well fix this. And often really slow opening can be virus and security software that grabs and holds the file - so test that issue also.

    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada


    • Edited by Albert D. Kallal Thursday, January 22, 2015 11:57 PM
    • Marked as answer by Caillen Tuesday, February 3, 2015 2:40 PM
    Thursday, January 22, 2015 11:57 PM