none
Access 2010 drivers x64 edition & registry entry RRS feed

  • Question

  • G'day,

    I've downloaded the x64 edition of the Office 2010 drivers, hoping to
    upgrade my .net applications that interact with Excel data files to a x64
    solutions.
    http://www.microsoft.com/downloads/details.aspx?FamilyID=C06B8369-60DD-4B64-A44B-84B371EDE16D&displaylang=en

    When I install the x64 edition it doesn't seem to add any entries to the
    registry location I expected to see the entries.

    Expected: "HKLM\SOFTWARE\Wow6432Node \Microsoft\Office\14.0\Access Connectivity
    Engine\Engines\Excel"


    Actual: "HKLM\SOFTWARE\Microsoft\Office\14.0\Access Connectivity
    Engine\Engines\Excel".

    Is this the correct registry entries for the Access 2010 drivers or is the installation incorrect?

    I noticed while looking at the registry that there were some references to ACEEXCL.DLL which is located in the x64 C:\Program Files\Common Files\Microsoft Shared\OFFICE14 directory rather than the C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE14 folder on the x64, which implies this is a x64 file. Just a little confussed with the registry entries.

    I've also entered a cross post at the following location.


    Jamie Clayton http://www.jenasysdesign.com.au
    • Edited by Jamie Clayton Thursday, June 17, 2010 1:04 AM Added a better explaination of the file locations.
    Thursday, June 17, 2010 1:01 AM

Answers

All replies

  • Hello Jamie,

     

    Welcome to ADO.NET Managed Providers forum!

     

    Since we install the x64 version of Office 2010 driver on x64 Windows, the registry entry should be correct.   J   

     

    The Wow6432Node entry stores the information of x86 drivers or applications which is running on x64 platform as Wow64 mode.  

     

    For the Wow6432Node, I also used it in this thread to enable ADO.NET Tracing, http://social.msdn.microsoft.com/Forums/en-US/adodotnetdataset/thread/2c3beec5-3fba-4644-a496-1bddb944e246.  

     

    Good day!

     

     

    Best Regards,
    Lingzhi Sun

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Thursday, June 17, 2010 6:58 AM
    Moderator
  • Hi Jamie,

     

    I am writing to check the status of the issue on your side.  Would you mind letting us know the result of the suggestions? 

     

    If you need further assistance, please feel free to let me know.   I will be more than happy to be of assistance.

     

    Have a nice day!

     

     

    Best Regards,
    Lingzhi Sun

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Wednesday, June 23, 2010 1:58 AM
    Moderator
  • Lingzhi,

    Thank for the support. I guess I'm learning about x64 implementations now. I'm a bit frustrated that it's taking more time than I expected it to. I've also got a cross post with Nunit support as I crash their product while testing my Excel 2010 x64 code base.  See https://bugs.launchpad.net/nunitv2/+bug/597265

    I'm happy to supply all my code to you if needed.  I'll make the logic changes and run the ADO.net tracing with the code an re-test. I've got a bit of time to resolve the issue as the software changes will require the customer to migrate their whole company from XP x32 Office 2007 to Windows 7 x64 + Office 2010 (16 of 200 users), so it's not going to happen overnight.

    I'll keep you informed.

    Thanks very much!


    Jamie Clayton http://www.jenasysdesign.com.au
    • Edited by Jamie Clayton Wednesday, June 23, 2010 10:55 PM Spelling mistake
    Wednesday, June 23, 2010 10:54 PM
  • But what is the actual issue with x64 implementation beside NUnit? Are you able to connect to Excel?
    Val Mazur (MVP) http://www.xporttools.net
    Thursday, June 24, 2010 10:33 AM
    Moderator
  • Hi Jamie,  

     

    How are you?   Any update of this case? 

     

    Good day!

     

     

    Best Regards,
    Lingzhi Sun

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, June 28, 2010 9:16 AM
    Moderator
  • G'day,

    I've learnt a lot about the Excel 14 implementation and x64 now and the matching registry and file paths. For instance the Office 14.0 Excel connection string is the same as the Office 12.0 edition (just to make things non intuitive).

    E.g.

    Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0};Extended Properties="Excel 12.0 Xml;HDR=No;IMEX=1"; {THIS WORKS}

    Provider=Microsoft.ACE.OLEDB.14.0;Data Source={0};Extended Properties="Excel 14.0;HDR=No;IMEX=1"; {THIS DOESN'T WORK}

     

    I'm also running into difficulties running Nunit.exe with Nunit Libraries in VS2010. If I use the Start External Program C:\Program Files (x86)\NUnit 2.5.5\bin\net-2.0\nunit.exe JD.Data.Nunit.dll /Cleanup I get the following exception, which seems to interfere with Nunit recompiling and running in the GUI. I suspect a "Run As Administrator issue".

    System.UnauthorizedAccessException was unhandled
      Message=Access to the path 'JD.Data.DLL' is denied.
      Source=mscorlib
      StackTrace:
           at System.IO.Directory.DeleteHelper(String fullPath, String userPath, Boolean recursive)
           at System.IO.Directory.Delete(String fullPath, String userPath, Boolean recursive)
           at NUnit.Util.DomainManager.DeleteShadowCopyPath()
           at NUnit.Gui.AppEntry.Main(String[] args)
           at NUnit.Gui.Class1.Main(String[] args)
      InnerException:

    The core problem with reading Excel data via the Office 14.0 drivers on x64 using a x64 compiled .net application and Nunit 2.5.5.10112 to automate testing lies in the following test method.  If I run the full class of nunit tests the method causes nunit to CRASH (not exception or fail, but APP CRASH which sends info to Microsoft crash reporting).  If I run the test method by itself it doesn't crash and passes :).

    The following line of the Nunit test seems to cause Nunit to crash (3rd reading of Excel spreadsheets).

           
            objDS = objExcel.GetDataSet(System.IO.Path.Combine(GetCurrentPath, "TestData\WithDataInSheet1.xlsx"), "Sheet1$B2:D10")

    <Test()> Sub ReadExcel()
        Dim objExcel As New JD.Data.Excel
        Dim objDS As New System.Data.DataSet
    
        '  Sheet Name
        Console.WriteLine(String.Format(cNunitMessage, "Sheet Name"))
        objDS = objExcel.GetDataSet(System.IO.Path.Combine(GetCurrentPath, "TestData\WithDataInSheet1.xls"), "Sheet1$")
        If objDS.Tables.Count = 0 Then
          Assert.Fail("No data returned")
        End If
    
        '  Sheet Name with space
        Console.WriteLine(String.Format(cNunitMessage, "Sheet Name with space"))
        objDS = objExcel.GetDataSet(System.IO.Path.Combine(GetCurrentPath, "TestData\SheetNameWithSpace.xls"), "Sheet 1$")
        If objDS.Tables.Count = 0 Then
          Assert.Fail("No data returned")
        End If
    
        '  Sheet Name and Row/Column Reference    
        Console.WriteLine(String.Format(cNunitMessage, "Sheet Name and Row/Column Reference"))
        objDS = objExcel.GetDataSet(System.IO.Path.Combine(GetCurrentPath, "TestData\WithDataInSheet1.xls"), "Sheet1$B2:D10")
        If objDS.Tables.Count = 0 Then
          Assert.Fail("No data returned")
        End If
    
        '  Named Range
        Console.WriteLine(String.Format(cNunitMessage, "Named Range"))
        objDS = objExcel.GetDataSet(System.IO.Path.Combine(GetCurrentPath, "TestData\NamedRange.xls"), "SimpleDataRange")
        If objDS.Tables.Count = 0 Then
          Assert.Fail("No data returned")
        End If
    
        '  Empty Spreadsheet
        Console.WriteLine(String.Format(cNunitMessage, "Empty Spreadsheet"))    
        objDS = objExcel.GetDataSet(System.IO.Path.Combine(GetCurrentPath, "TestData\Empty.xls"), "Empty$")
        If objDS.Tables.Count = 0 Then
          Assert.Fail("Expected dataset")
        End If
    
        '  First Spreadsheet
        Console.WriteLine(String.Format(cNunitMessage, "First Spreadsheet"))
        objDS = objExcel.GetDataSet(System.IO.Path.Combine(GetCurrentPath, "TestData\WithDataInSheet1.xls"), 0, False, False)
    
        '  Read a spreadsheet full of mixed policy numbers and confirmed no results are blank.
        Console.WriteLine(String.Format(cNunitMessage, "Read a spreadsheet full of mixed policy numbers and confirmed no results are blank"))
        objDS = objExcel.GetDataSet(System.IO.Path.Combine(GetCurrentPath, "TestData\MixedColumnData.xls"), 0, False, True)
    
        If objDS.Tables.Count = 0 Then
          Assert.Fail("Expected dataset")
        Else
          With objDS.Tables(0)
            Assert.AreEqual(18, .Rows.Count, "Expected 18 rows of mixed data")
            For intLoop As Integer = 0 To .Rows.Count - 1
              Debug.WriteLine(.Rows.Item(intLoop).Item(0).ToString)
              Assert.AreNotEqual("", .Rows.Item(intLoop).Item(0).ToString.Trim, "Problem at row " & (intLoop + 1).ToString)
            Next
          End With
        End If
    
        If objDS.Tables.Count = 0 Then
          Assert.Fail("Expected Empty dataset")
        End If
    
        '  Extended test of a much larger alpha numeric file with NO column headers.
        Console.WriteLine(String.Format(cNunitMessage, "Extended test of a much larger alpha numeric file with NO column headers"))
        objDS = objExcel.GetDataSet(System.IO.Path.Combine(GetCurrentPath, "TestData\MixedColumnData_LargeWithNoTitleRow.xls"), 0, False, True)
    
        If objDS.Tables.Count = 0 Then
          Assert.Fail("Expected dataset")
        Else
          With objDS.Tables(0)
            'Assert.AreEqual(903, .Rows.Count, "Expected 903 rows of mixed data")
            For intLoop As Integer = 0 To .Rows.Count - 1
              Debug.WriteLine(.Rows.Item(intLoop).Item(0).ToString)
              Assert.AreNotEqual("", .Rows.Item(intLoop).Item(0).ToString.Trim, "Problem at row " & (intLoop + 1).ToString)
            Next
          End With
        End If
    
        '  Extended test of a much larger alpha numeric file with column headers.
        Console.WriteLine(String.Format(cNunitMessage, " Extended test of a much larger alpha numeric file with column headers"))
        objDS = objExcel.GetDataSet(System.IO.Path.Combine(GetCurrentPath, "TestData\MixedColumnData_LargeWithTitleRow.xls"), 0, True, True)
    
        If objDS.Tables.Count = 0 Then
          Assert.Fail("Expected Empty dataset")
        Else
          With objDS.Tables(0)
            Assert.AreEqual(904, .Rows.Count, "Expected 18 rows of mixed data")
            For intLoop As Integer = 0 To .Rows.Count - 1
              Debug.WriteLine(.Rows.Item(intLoop).Item(0).ToString)
              Assert.AreNotEqual("", .Rows.Item(intLoop).Item(0).ToString.Trim, "Problem at row " & (intLoop + 1).ToString)
            Next
          End With
        End If
    
        objDS = Nothing
        objExcel = Nothing
      End Sub

     


    Jamie Clayton http://www.jenasysdesign.com.au
    Monday, June 28, 2010 11:31 PM
  • I'm duplicating the nunits 2.5.5 tests with Microsoft VS 2010 unit test to see if that help resolve some of the issues I've found trying to get VS 2010 and Nunit 2.5.5 working under x64.

    Jamie Clayton http://www.jenasysdesign.com.au
    Tuesday, June 29, 2010 11:45 AM
  • I can crash MS Test from VS2010 with the same unit tests in x64 mode.

    VS 2010 MS Test crash Report

    Problem Event Name:    APPCRASH
      Application Name:    QTAgent.exe
      Application Version:    10.0.30319.1
      Application Timestamp:    4ba20efa
      Fault Module Name:    msxml6.dll
      Fault Module Version:    6.30.7600.16385
      Fault Module Timestamp:    4a5bdfc8
      Exception Code:    c0000005
      Exception Offset:    00000000000016d1
      OS Version:    6.1.7600.2.0.0.272.7
      Locale ID:    3081
      Additional Information 1:    3cfc
      Additional Information 2:    3cfc6c6d14bdc651a9c8274b1b406d59
      Additional Information 3:    edd5
      Additional Information 4:    edd5622e8ad533d3357f6496dc3c65f4

    The Nunit crash report looks to be in exactly the same module.

      Problem Event Name: APPCRASH
      Application Name: nunit-agent.exe
      Application Version: 2.5.5.10112
      Application Timestamp: 4bd0d2b8
      Fault Module Name: msxml6.dll
      Fault Module Version: 6.30.7600.16385
      Fault Module Timestamp: 4a5bdfc8
      Exception Code: c0000005
      Exception Offset: 00000000000016d1
      OS Version: 6.1.7600.

    2.0.0.272.7
      Locale ID: 3081
      Additional Information 1: 3cfc
      Additional Information 2: 3cfc6c6d14bdc651a9c8274b1b406d59
      Additional Information 3: edd5
      Additional Information 4: edd5622e8ad533d3357f6496dc3c65f4

     

    Reading excel files individually seems to pass unit tests, but if you have a class that reads many excel files and you re-use that to read multiple excel files the application crashes in Windows x64, but doesn't in a x86 environment.


    Jamie Clayton http://www.jenasysdesign.com.au
    Wednesday, June 30, 2010 6:41 AM
  • Further experimentation with MS Test indicates the x64 edition of Office 2010 drivers will pass unit tests and DO NOT crash the QTAgent.exe if you select "Run All Tests within the solution " VS2010 menu option. If you select "Debug All Tests within the solution " you WILL CRASH QTAgent.exe and send crash reports to Microsoft. I'm now getting the impression that the VS2010 debugging environment in x64 is part of the problem. Nunit just doesn't seem to like that configuration either as you can't set any breakpoints in your code. BTW, I'm using VB.net for all these tests.
    Jamie Clayton http://www.jenasysdesign.com.au
    • Edited by Jamie Clayton Wednesday, June 30, 2010 11:04 AM formating
    Wednesday, June 30, 2010 11:02 AM
  • Hi Jamie,

     

    Thank you so much for providing us with the detailed information!!!   I think it is definitely beneficial to other community members!   J

     

    I will mark my first post as the answer since it solve the original question in this thread.   For every post of yours, you own my helpful votes!

     

    Good day!

     

    Best Regards,
    Lingzhi Sun

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Thursday, July 1, 2010 7:16 AM
    Moderator