FRx with Dynamics GP 2015

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 really 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 really only uses ODBC to connect to the GP databases (in company setup in FRx, where you tell is what ODBC connection to use). 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 that 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: you couldn’t log in.

The error text was “The login failed for the <your company> company. Make sure the login ID and password are correct and verify the settings on the System Specific Information page in Company Information.” Then the supplemental details “Frx32.OFSIMain.CheckOFSIConnection. 8900: 438FrxMBSUtilObject doesn’t support this property or method”.

FRx error on GP2015

None of that immediately triggered any ideas for me. Knowing the licensing changed for GP, the only thing I wondered was is the login 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-land 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 you can’t use the same login for FRx that you use for Dynamics GP because GP logins are encrypted. Sorry… spreading of misinformation pisses me off, whether you’re aware you 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. If you are 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 you don’t use 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 you to the GP company you 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. The more specific you are, often you get better results to fix your 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, or 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. If you are an end-user, 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 screen shot 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 you if you are searching to find resolutions! No one would ever find your 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 those 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 for 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:

FRx installed GPconn dll properties

The version on Constance’s website is this:

FRx old GPconn dll properties

And this is where I put it to make FRx work on GP 2015. I simply renamed the old/new one.

FRx GP2015 common files

By the way, while researching for this post, I came across this article which explains how the GPConn.dll is used. Old article but the substance is still valid.

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 your environment. If you have customizations, VBA or Visual Studio or other integrations in your 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 you make changes like this!

(originally posted on www.kuntzconsulting.ca, and migrated to this site in October 2017)

19 thoughts on “FRx with Dynamics GP 2015

  1. Reply
    Sean - May 1, 2015

    This is a great post!

    I to spent many hours trying to get FRx to work after installing GP 2015.

    I am not sure if you touched on this, but in the dexterity folder, I simply renamed the GPConn.dll installed with GP 2015 to GPConn_v2015.dll (or whatever you want).

    I then navigated to where the FRx software folder is installed C:Program Files (x86)FRx SoftwareFRx6.7

    Look for the FRxReg67.cmd. Launch this and let run to completion. Once completed you will find the original GPconn.dll in the dexterity folder. FRx should work.

    Feel free to add this to your post. Thanks for your time!!

    Sean

    1. Reply
      Jen Kuntz - May 20, 2015

      Hi Sean,
      Thanks for the comment. I didn’t reply earlier since I didn’t have a chance to test this. I got a chance to try this because the GPconn.dll was overwritten when I installed the latest GP2015 service pack. I tried your method above (rename GPconn.dll and then run the FRxReg67.cmd) and no new DLL was created.
      The only interesting thing is the error message is now different for me when I try to login to FRx, now it says “FRx is unable to establish a connection to the general ledger. Verify that GPConn.dll exists on your computer and that it is registered”. If the original message were so obvious, the troubleshooting might have been quicker!
      Jen

    2. Reply
      Jen Kuntz - May 20, 2015

      OK… a second update! I thought I’d run the FRxReg67.cmd a second time and this time the GPconn.dll shows up. Very strange, but thanks for the tip! This is much easier than tracking down an older copy of GPconn.dll for sure.
      Jen

  2. Reply
    Michael La Brie - July 7, 2015

    Jen,

    Thank you for posting this item. I just ran across it this week and was scratching my head trying to figure out how GP 2015 could break FRx. Your post saved me a lot of time. First beverage is on me at the next conference.

    1. Reply
      Jen Kuntz - July 8, 2015

      You’re welcome Mike! See you in Fargo in September?

  3. Reply
    Maria Price - July 24, 2015

    Can’t thank everyone enough for this post!! Total life saver for me and it worked great.

    Thank you,
    Maria Price

    1. Reply
      Jen Kuntz - July 28, 2015

      You’re welcome Maria! Really, the person to thank though is Constance Quiqley from Q Factor… without her original post, I would have also been lost!

  4. Reply
    Dave T - August 13, 2015

    Hi Jen,

    For your information if the GPconn.dll is replaced the following will fail in GP2015R2:
    – Analytical Accounting query wizards
    – Analytical Accounting budget imports and exports.

    If Analytical Accounting is used I would definitely recommend using management reporter over FRx.

    Thanks
    Dave T

    1. Reply
      Jen Kuntz - August 13, 2015

      Thanks Dave. It’s good to have a specific example of where replacing the GPconn.dll with something older is not a good idea!

  5. Reply
    brian connell - October 13, 2015

    We have used this solution multiple times but ran into trouble. A recent upgrade to GP2015 R2 from GP2010 we received an error referencing the FSGreatPlains61.dll file. I had to replace the file with one dated 10/2005 ( the install had one dated 2/2011). I replaced the dll, ran the frx67reg.cmd, then re-setup the companies.

    1. Reply
      Jen Kuntz - October 13, 2015

      Thanks for the comment Brian. I found the same thing at an upgrade two weeks ago, same upgrade path as you mentioned. I’ve been using the frx67reg.cmd approach and it seems to work every time so far (limited test data though)!

  6. Reply
    Victoria Yudin - November 29, 2015

    Thanks Jen! I tried copying the file from an older GP install where FRx is working fine (GP 10.0), but that did not work. So I deleted the GPConn.dll and re-ran FRx 6.7 SP 12 (I thought I would try that before re-installing the whole thing), even thought it was already installed. That recreated the DLL with a 2006 version that worked perfectly.

    -Victoria

  7. Reply
    Joseph Markovich - January 4, 2016

    THANK YOU Jen for this post!

    After fixing that, I have a new error when the users try to launch a report:

    Source: FSGreatPlains61
    Error 40002: 37000: [Microsoft][SQL Server Native Client 11.0][SQL Server] The batch could not be analyzed because of compile errors.

    Is there anything I can do to get FRx to work?

    Thanks.

    -Joe

    1. Reply
      Jen Kuntz - January 4, 2016

      Hi Joe,

      Based on the error message you have, which I’ve never seen so it’s purely a troubleshooting approach, you might want to try setting up a regular SQL ODBC connection that isn’t Native Client. One of my clients I keep a SQL Server ODBC connection for FRx that isn’t the same ODBC as what you use for GP client apps. Each company setup in FRx would need updating to “use” the new ODBC connection so take notes of what you change in case it does not work out as planned!

      Jen

  8. Reply
    bruce - August 17, 2016

    SOMETIMES third party dotNet applications in ADDINS directory that independently login to Great Plains use the GPConn.dll file

    1. Reply
      Jen Kuntz - August 17, 2016

      Bruce, very true! Thanks…

  9. Reply
    Vic - November 17, 2016

    Very useful blog. Thank you! Other issues I ran into and the solutions:

    1) We hit the compile errors issue. I created a new ODBC Connection using Native Client 10 and updated all the companies which got us past that.

    2) **MOST IMPORTANT** Make sure you are running the latest release/SP of FRX: 6.7.12008 – Service Pack 12. We were on 6.7.9111 for years in GP2010 without issue, mind you, we were also on older OS (TS 2008, SQL 2005) Our migration to 2105R2 involved us moving to TServer 2012 and SQL 2014. Applying Service Pack 12 resolved the other issues we ran into.

    3) We had some unusual behavior on Terminal Server under Citrix. We set the FRx to run in compatibility mode

  10. Reply
    Victoria Yudin - November 28, 2017

    Hi Jen, I think I found a situation where this does not work – running FRx locally on a machine that has dual monitors set up. Just wanted to share this and also see if you or anyone else has come up with a solution for it.

    Thanks!
    Victoria

    1. Reply
      Jen Kuntz - November 28, 2017

      Wow, that’s kind of fascinating! I’m curious why dual monitors would have any impact on that…

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top