on 02-10-2011 9:54 PM
Hi
I'm aware that this issue has been raised before, but I'm still struggling to understand how to fix this.
On my laptop I'm running the following:
Magic Software iBOLT Suite 3.2 SP2
Microsoft SQL Server 2008 R2
SAP Business One 8.8 (8.80.237) PL: 19
The remote server is running the following:
Microsoft SQL Server 2005
Business One 2007 A (8.00.181) SP: 00 PL: 47
When I attempt to connect to Business One 2007 A (8.00.181) SP: 00 PL: 47, via iBOLT, on the remote server it returns the "OBServer DLL Version Mismatch" error. Even though I specify that the DI API Version I'm connecting to is 2007.0
I've tried unregistering SAPbobsCOM88.dll and tried registering SAPbobsCOM2007.dll, but none of this has helped.
I've tried uninstalling the 8.8 DI API and reinstalling the 8.8 DI API; I've also tried rerunning Upgrader Common.
Is it absolutely not possible to connect to Business One 2007 A (8.00.181) SP: 00 PL: 47 remotely if I'm running SAP Business One 8.8 (8.80.237) PL: 19 locally? This doesn't seem like a very efficient way of doing development, as I will need to exactly match my local environment to every single client's remote environment whenever I need to do any development.
I will also post this with iBOLT support, but it sounds more like an SAP issue.
Could somebody please assist?
Many thanks,
Carl
Hi Carl,
Welcome you post on the forum.
To handle this issue, you need at least Terminal Server or Citrix Server to connect. Unless you have virtual OS installed and switch between your local B1 and some other OS for remote, RDP or Citrix client will be the most efficient remote connection tools.
Thanks,
Gordon
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Gordon
When I first experienced the issue I only had the SAP Business One 8.8 (8.80.237) PL: 19 DI API installed.
Every time I tried to validate the connection to the SAP Business One 2007 A (8.00.181) SP: 00 PL: 47 instance on the remote server, I would receive the "OBServer DLL Version Mismatch" error. I don't understand why this should be a problem, as I have looked at the DI API installation directory and it contains all the required legacy DLLs. Furthermore, when the connection is first established, it downloads OBServerDLL.dll from the remote server it connects to.
I have since uninstalled the SAP Business One 8.8 (8.80.237) PL: 19 DI API and installed the SAP Business One 2007 A (8.00.181) SP: 00 PL: 47 DI API; I am now able to successfully connect to the remote instance of SAPB1 2007. Please note that it has to be the exact same DI API version as the remote SAP instance. I tried installing SAP Business One 2007 A (8.00.239) SP: 01 PL: 13 DI API and again received the "OBServer DLL Version Mismatch" error. I also tested this with a small VB application.
Does this mean that every time I do development, I will need to uninstall my current DI API and install the identical DI API version our customer is running?
Something doesnu2019t seem correctu2026
Why does the DI API installation even bother to contain legacy DLLs then?
Whatu2019s the reason for the client application downloading OBServerDLL.dll when it first connects to the server?
Iu2019m confused at how complicated this whole procedure seems to be.
Thanks,
Carl
You have a misunderstanding of where the error is actually coming from but you have in the end found the correct solution.
When you try to connect the DI to a B1 system, it first has to make the connection with the SBO-COMMON. In making this connection, it downloads the OBServerDLL from the SBO-COMMON - the reason for the actual download, I have never been 100% certain of.
However, the limitation is your DI which is connecting must be the same patch as the SBO-COMMON (on the server of the DB you connect to. DI versions installed on this server have no bearing, it is only the PL of the SBO-COMMON that matters). The reason for this does make sense - older versions might still contain bugs which have been fixed and shouldn't be allowed to happen again (or old features which have been removed and are not allowed) & new versions might contain new features which you shouldn't use on this lower PL.
In the end, the procedure isn't that complicated - although I can't explain the "why" of the legacy APIs and the download every time.. You must have same PL as the SBO-COMMON you are connecting to, so just delete SM_OBS_DLL from your temp folder, uninstall the wrong DI and install correct DI.
Hi njmog1
Thanks for adding some clarity in the fact that it is the version of SBO-COMMON which is the critical component.
What exactly does OBServerDLL do?
I completely agree with what you say about the pitfalls of different versions communicating with each other.
However, I would expect the DI API to be backwards compatible.
Furthermore, this is why I thought that OBServerDLL was stored in SBO-COMMON and downloaded upon an initial connection.
For example, I am running SQL Server 2008 R2 locally on my laptop, but I have no difficulty in connecting to a remote instance of SQL Server 2005.
I'm not sure if you've used iBOLT, but it specifically let's you specify the DI API version you are connecting to for this very reason. If the DI API version is not specified, then iBOLT defaults to using the same DI API that is installed locally. This would lead me to believe that regardless of which DI API I have installed locally, I should be able to override this and remotely connect to any version of the DI API (or SBO-COMMON to be more accurate). I have raised this as an issue with the iBOLT vendor and they are investigating this unexpected behaviour.
Anyway, I'm glad that I have managed to get things working, but I still have some unanswered questions.
Regards,
Carl
Edited by: carl.schutte on Feb 14, 2011 11:57 AM
User | Count |
---|---|
91 | |
10 | |
10 | |
6 | |
5 | |
5 | |
5 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.