Have VBA code in MS Access to extract the list of users from BO 4.2. Code was working fine with Office 2013, but just updated to Office 2016 and now the code is failing.
Here’s a snippet:
'---Vars for BO Session---
Dim SessionManager As New SessionMgr
Dim esession As EnterpriseSession
Dim iStore As InfoStore
'---Vars for User Info---
Dim BOUsers As InfoObjects
Dim BOUserItem As InfoObject
Dim BOUserObject As User
'Dim BOUserObject As CrystalUserPluginLib.User
'Enterprise Session
Set esession = SessionManager.Logon(Me.tbUserName, Me.tbPassword, Me.cboCMS, Me.cboAuth)
'Infostore instanciation
Set iStore = esession.Service("", "InfoStore")
'--Get User Info
Set BOUsers = iStore.Query("SELECT TOP 1000000 SI_EMAIL_ADDRESS, SI_FORCE_PASSWORD_CHANGE, SI_NAME, SI_ID, SI_USERGROUPS, SI_USERFULLNAME, SI_ALIASES, SI_DESCRIPTION, SI_LASTLOGONTIME, SI_PASSWORDEXPIRE, SI_NAMEDUSER FROM CI_SYSTEMOBJECTS Where SI_KIND='User'")
For Each BOUserItem In BOUsers 'Loop through users
Set BOUserObject = BOUserItem
The code is now failing on the last line above, setting BOUserObject = BOUserItem
The error being generated is: 13 - Type mismatch 1000013
I’ve tried declaring BOUserObject as User and as CrystalUserPluginLib.User. Both generate the same error.
All references are enabled and for giggles, I’ve tried turning them off and back on - no luck.
The only change was the Office upgrade.
Any ideas as to what is going on and how to fix this?
I don’t have a solution for you, but a couple of suggestions for debugging.
So BOUserItem is an InfoObject, but it’s failing to be cast to User. In your For loop, try the following instead of doing the cast:
Debug.Print BOUserItem.kind & " " & TypeName(BOUserItem)
If you get anything other than “User User”, then some other type of infoobject has made its way into the result. Though I can’t see how that would happen, since your CMS query is explicitly filtering on User objects only…
When I run the query in querybuilder, the data returned contains just users, as expected, nothing strange. When I put a watch on BOUsers, it’s showing a count of 45 objects being returned, which matches the number of users returned by query builder. Also get the same error pointed to our dev and prod environments, so it’s not enviro related.
Actually “User InfoObject” is expected, since User extends InfoObject. But the fact that they’re all “User …” proves that the results are in fact users and not something else.
I’m stumped. I can’t think of any reason why it wouldn’t properly cast to User. If the library wasn’t referenced properly, the project wouldn’t even start - you’d get a “user defined type not allowed” error on the Dim statement.
The only thing I can think of is that somehow the library got corrupted, and it’s not fully recognizing the reference. A re-install of the BO client software may resolve it.
A less risky, but possibly more labor-intensive solution would be to just use InfoObject instead of User. You would have to access the properties manually rather than using User’s accessor methods. So, instead of:
After much head scratching, found and resolved the problem.
Pulled the full path of the references to look at the files and see if anything got changed somehow. Discovered that User.dll and UserGroup.dll were coming from C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win32_x86 while InfoStor.dll and the others were coming from win64_x64.
When I checked win64_x64, neither User.dll nor UserGroup.dll existed (not sure why – maybe because Office 2013 was installed as 32 bit and 2016 as 64 bit – though why that would impact the install of just those files?).
Both files did exist in win64_x64 on the server, so I copied both to my local machine and registered the dlls. Then went into Access and updated the references to point to the 64 bit version and presto, everything is working again!
(BOB member since 2002-08-29)