We have quite an issue with the Smart3D VUE Plugin for Navisworks. The plugin uses and installs the 64-bit version of the Microsoft Access Database Engine regardless the Office version already installed. Microsoft Office does not support mixing modes and several features in Office breaks following the installation, i.a. Excel and Outlook. We could switch to x64 versions of Office, you might say, but this is where it gets tricky. Smart3D does not support x64 Office - only x86. Fixing a plugin that reads Smart3D exports by breaking Smart3D - the very program producing the files is awfully close to being a Catch 22. Any suggestions?
Solved! Go to Solution.
Solved by dgorsman. Go to Solution.
Export on a computer with 32-bits office
and Import the Vue file on a computer with 64-bits office.
would be the obvious suggestion
That is indeed the/an obvious method and in fact roughly the workaround we use, by having an array of VMs without Office running Simulate and by way of a file system monitor, feeds Simulate with files automatically when dropped to those systems. This is a workaround and certainly not the optimum solution. We have way too many users for that.
Which version of Office are you using?
We use Microsoft Office 2010 x86 on Windows 7 x64. We are currently in the process of rolling out Office 365 but still in x86 version due to compatibility with other applications. We are 13,000 employees with literally thousands of applications that interact in countless ways, so there is a balance to keep :-). Unfortunately Navisworks is only one tiny piece in the puzzle, if not (at least from my standpoint) a quite important one.
I would have only one special computer set up to convert the VUE files with data into an NWD
and then have all the other users open or append that NWD to the overall Collaboration model.
That one special computer may even to that conversion scheduled or only when a new version of a VUE model arrives.
In that way, you do not need every user world-wide to have the VUE reader and the right Office version installed.
That is exactly the workaround we have. It is fully automated (the pains of that setup caused by a bug in Simulate 2017 can be read elsewhere on this forum) but still instills some issues:
There are two scenarios that are covered by this method:
It certainly works but definitely not user friendly. We have a rather sophisticated queuing system we made our ourselves some years back that we are opening up now for new features. A system that can handle some of these problems. For some reason, however, the VUE plugin causes errors when accessing Simulate via the API. That's another story entirely.
2010 Office in x86 does indeed have some problems, and we had similar problems. That was one of the driving forces for updating everyone here to Office 2013, and thankfully IT was talked into rolling out the x64 version. In the 2013 version you can install the x64 Access driver separately; I think the required process is install that first, then the x32 Office program. Then programs on the computer have "access" to both drivers based on their own bit-ness.
I'm not certain how that interacts with Office 365 but it should work in a similar fashion.
Can't find what you're looking for? Ask the community or share your knowledge.