SAPGUI input history lost after Windows user-id change

[kimmo_sirpoma]

Could it be so, that if user's Windows user-id changes, then old sapgui input history from previous Windows user profile cannot be copied to new user-id?

This is a real case that happened:

User (for example PeterD) had used SAPGUI 7.3 patch for several months and had a huge sapgui input history file SAPHistoryPeterD.mdb in the Windows' c:\user\PeterD\appdata\Roaming\SAP\SAPGUI\history folder.

Then one day, Windows user-id changes (example from PeterD to ID12345) - but not the hardware (=laptop), meaning that Windows profile gets changed too but in this occasion the profile change was done in such way, that user's Windows profile folder did not changed (meaning that new userid ID12345 still allocated to C:\Users\PeterD). In the meantime no deinstallation of SAPGUI happened.

When first time after user-id change, logging to a SAP system with the old installation of SAPGUI 7.30, the user notifies his input history is lost.

Also, a new mdb-file is created with new name SAPHistoryID12345.mdb but is very small. User finds out soon, that during SAP session old input history is gone, but new input entries gets saved.

I happened to be the person to analyze the problem for this individual:

* Read lots of SDN threads and one blog particularly that deals with copying Input history to new machine => no help from that blog.

* old mdb-file still exists, having the name of SAPHistoryPeterD.mdb, but new mdb-file SAPHistoryID12345 exists too in the history folder and is very small size and timestamps indicating that it is newly created and SAPGUI currently uses that.

* closed SAPGUI and SAPLOGON for a while.

* renamed new mdb-file with a temporary name, and copied the old mdb-filed (PeterD's) to new name SAPHistoryID12345.mdb, same as the one SAPGUI had created when first started after first windows logon with new user-id.

* opening SAPLOGON and SAPGUI => no input history exists!

* Tracefile sapfewdll_01_0001_00_1372_1076.err.trc in folders C:\Users\ID12345\AppData\Local\SAP\SAP GUI\Traces says:

"CSapHistoryDb::CreateDB: Microsoft Access Database Engine Database already exists.

Error: Loading local DB failed in frontend."

* I uninstalled SAPGUI completely

* manually removed directory SAP and its subdirectories from folders c:\user\ID12345\appdata\local and c:\user\ID12345\appdata\Roaming

* installed SAPGUI 7.30 back again but this time with sapgui 7.30 patch5.

* There is nothing special in Windows Registry that could cause unwanted behaviour (there exists notes recommends to check certain SAP specific registry entries for input history)

* Opened SAPGUI again, which creates an empty mdb-file in the history folder, name being again SAPHistoryID12345.mdb.

* Input history of course works, but only for the new input values. Obviously.

* Then closed SAPGUI, and made the renaming of current mdb-file to a temporary name and copied the old mdb-file from PeterD's and renamed it to SAPHistoryID12345.mdb.

* Opened SAPGUI again => no input history at all! And same error in the trace file.

As a consequence of all try-and-error I had a second thought:

* Input history contains data that could have quite sensitive information.

* It is probably meant to be so, that mdb-files cannot be copied to other Windows user-id profile FOR SECURITY REASONS.

* I don't know how SAPGUI does the verification, but it apparently must do it by the content of mdb-file or some MS ACCESS level security features (the mdb-file have a MS ACCESS icon with LOCK sign in the icon). It fails to read mdb-file originating from a different user, and tries to create it as new, but finds it already existing thus providing the error in the trace file.

The final determination is:

* You cannot copy SAP input history between different user-id's even if the new user-id is assigned to same profile folder as the old user-id. And this is a security feature, not a bug. Probably it is said in some release notes or security declaration too, but not bother to find it anymore.

What do you experts say? Is my determination confirmed or busted?

br: Kimmo

[jude_bradley · Accepted solution]

Hello Kimmo,

Confirmed.

The database file is locked to both the userid and the workstation.

Regards,

Jude