cancel
Showing results for 
Search instead for 
Did you mean: 

SAP GUI Scripting in 64-bit Excel

5,631

Hello,

I recently upgraded Excel from 32-bit to 64-bit for the performance gains when working with large amounts of data. However, after doing this, my VBA scripts in Excel are no longer working. I get an error on the following line of code:

Set SAPGuiApp = CreateObject("Sapgui.ScriptingCtrl.1")

Error: "ActiveX component can't create object"

From my research, I've seen that there may be a work around by editing the registry. Is this still the best solution?

Excel for Office 365 MSO (16.0.10730.20348) 64-bit

SAP 7.40 Patch 12

Thanks!

Will

Accepted Solutions (0)

Answers (3)

Answers (3)

jude_bradley
Product and Topic Expert
Product and Topic Expert

Hello Will, this might help, but other than that, revert to a 32bit office, it's less performance hungry for users. 2689304-Usage of SAP GUI Scripting ROT Entry Helper (saprotwr.dll) by 64bit applications

Stefan-Schnell
Active Contributor
0 Kudos

Hello Jude,

thank you very much for this information.

Best regards
Stefan

former_member709020
Participant
0 Kudos

Hi ya'll. I know this post has been active for a while but I've had success with the registry edit getting wdtfuncs.ocx and sapfewse.ocx to work with Office 64-bit. The instructions below are for the Remote Function Call (wdtfuncs.ocx) but you can follow the same procedure for SAP Scripting Control (sapfewse.ocx), GUID {B90F32AD-859E-4EDD-BFAE-C9216849520C}. Now if I could only get this line of code to work I'd be in business...

Set SapGuiConn = SapGuiApp.OpenConnection("ECC Production", True)

Stefan-Schnell
Active Contributor
0 Kudos

Hello Will,

I tried a tiny script to check instantiation of Sapgui.ScriptingCtrl.1 with SAP GUI 7.60 Patch 1 HF 1 and the behaviour is the same.

On Error Resume Next
Set SAPGuiApp = CreateObject("Sapgui.ScriptingCtrl.1")
On Error Goto 0
If IsObject(SAPGuiApp) Then
  WScript.Echo "Object Created"
Else
  WScript.Echo "Can't Create Object"
End If
Set SAPGuiApp = Nothing

x86 runs without any problems and x64 don't.

Okay, you can find a registry hack here, maybe this solves your problem.

Let us know your results.

Best regards
Stefan

qurm
Participant

I recently needed to make some older VBA scripts (from Excel 32 bit), work with the newer Excel 64-bit. I am using SAP GUI 7.60 (7600.1.3.1156)

My error was also "ActiveX component can't create object" at this line

Set fns = CreateObject("SAP.Functions")

According to this note, the GUI 7.60 should set the registry keys "Therefore, as of patchlevel 8 of SAP GUI for Windows 7.50 and as of SAP GUI for Windows 7.60, the installation of SAP GUI for Windows automatically writes the respective registry values so that a usage of saprotwr.dll from 64bit processes is possible"

2689304-Usage of SAP GUI Scripting ROT Entry Helper (saprotwr.dll) by 64bit applications

However I found it did not work. I tried to use the registry hack as below, and can confirm that this did fix the problem. My GUID is

{5B076C03-2F26-11CF-9AE5-0800096E19F4}

  • Locate your COM object GUID under the HKey_Classes_Root\Wow6432Node\CLSID\[GUID]
  • Once located add a new REG_SZ (string) Value. Name should be AppID and data should be the same COM object GUID you have just searched for
  • Add a new key under HKey_Classes_Root\Wow6432Node\AppID\
    The new key should be called the same as the com object GUID

This step was not necessary - already set, maybe by the GUI 7.60 installer

  • Under the new key you just added, add a new REG_SZ (string) Value, and call it DllSurrogate. Leave the value empty
  • Create a new Key under HKey_Local_Machine\Software\Classes\AppID\
    Again the new key should be called the same as the COM object’s GUID. No values are necessary to be added under this key.

I will try the installation again with a later 7.60 GUI and a clean Windows 10 installation.

This is a more up-to-date and recent description of the registry change: https://docs.microsoft.com/en-us/windows/win32/com/registering-the-dll-server-for-surrogate-activati...

Sandra_Rossi
Active Contributor

qurm I also had the same positive result, and I agree everything you saide. About "This step was not necessary - already set, maybe by the GUI 7.60 installer", it's your own previous action ("Add a new key under HKey_Classes_Root\Wow6432Node\AppID\") which automatically added implicitly the OTHER registry key.

In the following two cases, if you create the first key, it will create another one implicitly:

  • HKEY_CLASSES_ROOT\WOW6432Node\AppID\TEST -> HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\TEST
  • HKEY_CLASSES_ROOT\AppID\TEST -> HKEY_LOCAL_MACHINE\SOFTWARE\Classes\WOW6432Node\AppID\TEST

HKCR and HKLM are somewhat inter-connected, it's better explained here: https://support.microsoft.com/en-us/help/256986/windows-registry-information-for-advanced-users

qurm
Participant
0 Kudos

Thanks Sandra - that makes sense.

I still am not clear why the 7.60 installation did not set this correctly, but will try again with the latest version.