Sage 100

FRx error when exporting to Excel - ""Excel unable to set font style . . .""). Client on 2013 & Excel 2013 got new Windows 7 computer. I installed to location outside Program Files. Installed all SP's. Did not install .NET 1.1. Applied Microsoft resolution 964427, made sure there are no spaces in path names, building block id's or export file name. Report output to viewer is ok. A file gets generated to IO_Data, but when try to open it, get attached message. Anyone run into this and resolved (short of retiring FRx?)

I' pretty sure I just had this and from memory it required that I: a. Install FRX 678 b. Install SP 11 c. Run the FRXReg67 Found that if I run the FRXReg67 BEFORE installing the SP it can continue to error out in some cases.

I've now run into this issue on a second client with a new computer, also on Excel 2013. In this case, I had previously installed .NET 1.1 and SPs 9-11. Ran FRXReg67 afterwards. Still getting the error. Anyone else have any additional input? Also, can anyone confirm that they have clients successfully exporting to Excel on Excel 2013?

I have kicked this thing up one side and down the other and still can't get this working for my clients. I have, however, installed FRx up through SU11 on a computer in our office running Sage 2013 and Office 2013 and successfully exported to Excel. I have posted on the old FRXBuzz site, as well as a rusty Microsoft user community post and hear crickets chirping everywhere. Before I throw in the towel, is there anyone else out there that has clients successfully exporting to Excel in this environment that can share their magic?

If it is 64 OS, did you install the 64 OS DLL's? Did all the SP's install to the correct folder? I have seen instances where the SP's don't default to the correct FRx folder. Only way to tell is to verify the version under Help.

Pretty sure I ran into this but have to look through some cases. My memory is that it may be a service update which it sounds like you tried.

@JeffSchwenk, which 64 OS DLL's are you referring to, and how would I have installed them? Here were my steps (all as admin) and the order in which I performed them: Installed FRx, installed SP9, then SP10. Copied MSXML.DLL from another workstation into SYSWOW64 and registered, installed SP11, ran FRXReg67. I will confirm install location of SP's. @WayneSchulz, I appreciate your checking your cases.

If your client is running workstation's that are 64 OS, there is one that need to be installed.

I looked at the case on this - unfortunately I don't see a resolution but I know they fixed it. My best guess is that it was to load FRX, then latest FRX SP then run the FRXREG67 which I've found I have to run after the latest service pack.

I looked at the case on this - unfortunately I don't see a resolution but I know they fixed it. My best guess is that it was to load FRX, then latest FRX SP then run the FRXREG67 which I've found I have to run after the latest service pack.

Wait a minute - the version under Help for client A is 6.7.8069! WTF? I specifically watched the install path when I ran the SP's to make sure it was to the folder I originally installed into. Checking with client B . . . In both cases, they are fat clients with SYSDATA on a network drive. Thanks to @JeffSchwenk for the reminder to check Help/About. Now, the journey continues . . .

Progress. When I first installed FRx on my WIN 7 laptop many many moons ago, I probably spent the entire day trying to figure out why the SU were not installing properly (as per the help about). I finally caught it. The folder that FRx installs the SU's to is NOT the correct folder!!!!!! I think it was one deeper than it should have been. On the next SP install, I changed the path and all was well. BTW, DON'T skip the SP's (thinking if you install the last one, it covers all the prior ones. For some reason, it doesn't. Spent another 4 hours with a client on this one. Finally contacted Sage. When we installed each SP in order (and verified via Help About). Life was better!!!

I've never had to install consecutive SP but have had to run the registry update too several times. I think it's FRXREG67?

Feeling like I'm at a dead end. Both clients show the release number from the install CD. Both are running fat clients with sysdata on a shared network drive. In the office here, the release number is for the latest installed SP. Installs are fat clients with local sysdata. Looking to see if SPs got installed elsewhere, but couldn't find any evidence. I compared the file organization on the local and found them to be identical outside of the sysdata location. Last call for more clues! Scheduled for discussions about alternatives with the clients . . .

This may sound silly or obvious, but did you check to make sure the message is not actually correct, and that the format you're exporting matches the filename? Could it be you're exporting as, say, csv, but the file name specified in the export is .xls?

Yes, I did. In another test, I opened the exported file, and saw that there were 1 or two lines in the file, which were descriptive - column titles. But then it was blank when there should have been GL data (i.e. no more rows appeared in the file).

I'd uninstall FRX completely and reinstall. Something weird is happening like two versions in different locations, etc. I agree FRX is a PITA to get running but I've had to reinstall FRX on several new computers and so far I've been able to get them all running.

I did that at one of the clients. Didn't get different results. :-(

I finally got this resolved for one of my clients! @JeffSchwenk - it was indeed the SP being installed into the wrong folder. In this case, I had installed FRx and then SP11. The SP got installed into the Report Manager folder underneath the main FRx folder on the workstation. Once I uninstalled the SP and re-installed into the parent folder, Voila!

Spent about a day and a half beating my head against the wall back when I got my first WIN 7 workstation. Made no sense at all..... Glad this worked for you.