Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Script Error running Windows 11 on ARM based PC (Surface Pro Copilot+)

I am upgrading my hardware to the new Windows Surface Pro Copilot+ which is a Qualcomm Snapdragon X Elite processor running Windows 11 for ARM. The PS scripts seem to run fine in collecting the data files, but generate an error when trying to build the CSV files. The first part of the error message(s) I get are:


Any help would be greatly appreciated.

Comments

  • I searched the internet for the error message:

    Exception calling "Open" with "0" argument(s): "The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.

    The top results seem to be about 32-bit OLEDB vs 64-bit OLEDB. I believe if you use 64-bit PowerShell, you need the 64-bit OLEDB and vice-versa.
  • edited September 24
    I am running 64-bit Windows 11 (version 24H2), however I notice that in the title bar of the window in my posted image it shows "C:\Windows\system32\cmd.exe". Does that mean it is running the 32 bit version of PowerShell?
  • My search results say this is the way to figure out if Powershell is 32 or 64 bits:

    https://stackoverflow.com/questions/8588960/determine-if-current-powershell-process-is-32-bit-or-64-bit
  • Thanks @newuser. Here is what I have tried (none of which seems to have worked):

    1. Determined version of PowerShell - followed directions on link you provided above as well as from https://howtogeek.com/731885/how-to-check-the-powershell-version-in-windows-10/. This indicated I am running the 64-bit version of PowerShell version 5 on ARM64 architecture:


    2. Based on directions from "TT's" reply at https://learn.microsoft.com/en-us/answers/questions/1658052/download-link-for-microsoft-ace-oledb-12-0, downloaded and installed 64-bit version (from the Wayback machine links in TT's response) and re-started my computer. Got the same error message when running the PS scripts.

    3. Uninstalled the application installed in Step 2 above and thought I would try the 32-bit version (what the heck). Repeated Step 2 downloading, installing 32-bit version, re-started computer, ran PS scripts - same error message.

    4. Noticed LucyChenMSFT-4874's response to original post in Step 2 above, indicating link for Microsoft.ACE.OLEDB.16.0 (which appears to be an upgrade to OLEDB.12), so thought I would give that a try. So I uninstalled 32-bit version installed in Step 3 above, downloaded and installed 64-bit version of OLEDB.16.0 (downloaded from https://microsoft.com/en-us/download/details.aspx?id=54920). Re-started my computer and ran the PS scripts - same error message

    5. Since that didn't work either, thought I would try the 32-bit version of OLEDB.16.0 from same link in Step 4 above. Uninstalled 64-bit version, downloaded and tried to install 32-bit version. Got the following error message:


    Any other thoughts on next steps?
  • Since your old machine works, I suggest using it to run the scripts. Personally I share the PortfolioSlicer data directory on my network and have a server update the scripts during the day.

    From any other device, they only need to read the data. This can work over the internet too if you secure everything.
  • @newuser I can do that, although I would like to retire my old machine at some point. I did a bit more research and found the following post:https://community.spiceworks.com/t/powershell-script-error/819031

    In it, a user by the name of "Neally" suggests (italics added) "Why are you using OLEDB to connect to Excel? I’d recommend to re-write your code to use the ImportExcel module by Doug Finke" and links to that module at https://github.com/dfinke/ImportExcel

    This looks more complicated that I am able to do, but would be interested in your thoughts on it as a possible solution/alternative.
  • edited September 25
    @newuser on second thought, it is more than simply "run the scripts" on the old computer. Since the scripts build the CSV files using the source file for symbols, transactions, etc., would also need to update and maintain the source file for new transactions, new symbols, etc. on the old computer, before running the scripts. Really the only thing that would be done on the new computer would be "Refresh All" in the Reports file.
  • Interesting... It does look very convoluted to use OLEDB to read an Excel file. It must have been all the original author of this script had back then. This will take some pondering to fix properly...
  • @gsbaker: Do you still need help resolving this issue?
  • edited September 26
    Yes, still looking for a permanent fix - so far I have not been able to get the script running on my new PC. @newuser has suggested a "workaround" that could work in the short term, but is kludgy. @newuser may also be looking in to a longer term fix using "ImportExcel" as a possibility.
  • Incidentally, I asked "CoPilot" about this error and here is the summary it provided as part of its more fullsome reply:

    "In summary, the error occurs because the Microsoft.ACE.OLEDB.12.0 provider is not registered or available for ARM architecture. Exploring alternative data access methods or running your script in an x86/x64 environment might be necessary."
  • @gsbaker - thank you for writing scripts that converted "OLEDB" logic to PowerShell "ImportExcel" logic. I included your script into re-release script library (as file GetExcelSrcData2.ps1) but for now just as optional script that is currently not enabled by default.
    To use these scripts you would have to:
    1. Rename script GetExcelSrcData.ps1 to GetExcelSrcData3.ps1
    2. Rename script GetExcelSrcData2.ps1 to GetExcelSrcData.ps1
    3. As per @gsbaker instructions included in the script - you need to start PowerShell in admin mode and install ImportExcel module by executing command:
    Install-Module -Name ImportExcel -Scope AllUsers
    4. Test extracts and confirm all works OK.

    We will consider promoting @gsbaker script to "main" branch in the future after we will consider all implications.

    @gsbaker - Thank you again for sharing your script with us!
Sign In or Register to comment.