Recently I've been playing with Microsoft Azure and installing Dynamics GP 2015 on Azure, upgrading my GP 2010 test environment etc.
One of the things I needed to try to get working was FRx. I haven't gotten to the point of adding Active Directory on Azure yet, therefore I don't have a domain and can't install Management Reporter. Same. Old. Problem. I hate that MR requires a domain, it limits test and demo capabilities in my opinion… but I won't rant on that right now! I figured FRx might work - albeit unsupported - since I thought it only uses ODBC to connect to the GP databases (in the company set up in FRx, where the ODBC connection to use is configured). So, what really would prevent it from working? Here's what I found… and full disclosure, I didn't resolve this myself, another blogger thankfully posted her solution and it worked for me. I figured I'd write about it again just because there are people out there who might need it to work temporarily until working on advancing their skills and installing a domain like I plan to.
The error message
Installing FRx itself was normal, no issues there. Launching FRx, and logging in, was where the issue occurred: I couldn't log in.
None of that immediately triggered any ideas for me. Knowing the licensing changed for GP, the only thing I wondered was if the login was now doing any validation on the type of user or something, that FRx wouldn't be aware of. Who knows. I tried my usual user login as well as 'sa', to rule out a GP user login issue. Still didn't work.
Off to Google to see if someone else had the same problem. (Yes, I should probably be using Bing… oh well…)
Searching for this issue
I tried various things to find this issue and couldn't find anything with the same "details". Lots of hits when searching for something like "The Login Failed FRx Dynamics GP"… pretty common problem. Most of the resolutions were ODBC-related - mixing up using IP vs. machine name etc.
Side note: I found one Dynamics community post, where someone whose credentials would be thought to be a reliable source of information, replying to the posted question telling them they can't use the same login for FRx that they use for Dynamics GP because GP logins are encrypted. Sorry but the spreading of misinformation pisses me off, whether the poster is aware they are wrong or not. Someone is going to find that post and declare their problem not solvable and create a bunch of new logins for no reason.
Most clients I've been at use the same login for FRx that they use for GP without any issue. When using FRx security, I usually recommend windows authentication so the user only had to "log in" to GP using their regular GP login and password, FRx will authenticate them for its own security via windows. If not using windows authentication it is messier, but often I recommend clients use the same login as GP, and set their FRx password to the same password as GP. That way, it's one login/password that authenticates them for both. Otherwise the user feels they are logging in twice and can easily get confused. One login is to authenticate to open FRx Designer itself, and the second login prompt is to authenticate the user to the GP company they are trying to run reports against. There is no issue with GP encryption in FRx!
OK, rant over.
Search tips… here's what works for me 90% of the time when searching for an issue:
- Search first for the exact error message. More specific searches often get better results to fix a problem.
- If there are error messages with additional info, I often skip searching on the initial text and type in the specifics in the detail section. If I get no hits or very few results from that, I try searching for parts of it, in case there is a common core error that is more generic.
- If I get hits that have nothing to do with the application itself, I will add Dynamics GP, GP 2010 or things like that to the search text, to try to get relevant results.
I rarely search Partnersource/Customersource knowledgebase - frankly, I find it horrible to search. I will often go to the Partner Technical Forums next if public searching doesn't result in anything helpful, as their forum is not indexed publicly. For end-users, the Dynamics Community forums are an equivalent place to try for help although those results will show up in search engine results too.
Most of the time what I've outlined about is sufficient to find what I need. For my part, when I blog about errors, I intentionally try to include in-text what the error message screenshot says, knowing that I am searching for a very specific phrase in an error message. Posting the error message image is great for visuals, but it doesn't help if searching to find resolutions! No one would ever find a blog post to see if it may help them.
So, in this case, nothing in the results of more generic searches helped me; I read enough of them to get the gist of the reasons why those users had similar issues and none of them applied to me. Searching for more specific text also struck out, I thought the "438FRxMBSUtilObject" might get a hit, and had a feeling that was the key, but I didn't get a hit.
Last effort, let's try googling "FRx and Dynamics GP 2015". Voilà! Constance Quigley from Q Factor already blogged about this and although the text and issues she had were slightly different from mine, the solution she had worked perfectly.
The Solution
The newest version of the GPConn.dll file installed with Dynamics GP 2015 doesn't work with FRx, which isn't a surprise since FRx isn't supported on GP 2015. The workaround Constance found was to use an older GPConn.dll file in the common files directory instead, and that worked for her and me. I used the one she has in her comments. The alternative to using that one would be to get one from an older install of GP that works with FRx.
The version that came with GP 2015 that I installed is this:
The version on Constance's website is this:
And this is where I put it to make FRx work on GP 2015. I simply renamed the old/new one.
Caveats!
I've written this for those who don't have a domain for using Management Reporter, for test environment purposes. I don't recommend following this in a production environment without discussing it with your partner first. GPConn.dll is used or can be used in other places and simply "backdating" to use an older version can easily result in breaking something else in the environment. If there are customizations, VBA, Visual Studio or other integrations in the environment, chances are good that they may reference GPConn.dll. There may be other uses of this that I am not aware of with third-party applications so beware and test this first, before making changes like this!
