Hello,

I have a client currently experiencing problem closing.

If the financial reporter is opened and immediately closed with no statement actually being opened, the financial reporter closes quickly and without a problem.

However if a statement is simply opened and the financial reporter is closed, it hangs up 100% of the time. Sometimes it will close after 4 or 5 minutes of a "not responding" window. Other times the user must use task manager to close.

Client using Windows Server 2008 Enterprise, Cat5E cable with network running at 100Mps despite GB switches.

Workstation is XP with 3.25 GB or Ram

Ledger Version 9.0D(111017)

What does the Task Manager show LedgerFinRep doing?

Does the same thing happen with a copy of their data on:
1) A local Drive
2) On your office machine/laptop

HI Michael,

Further testing today actually determined the following:

- Financial reporter froze (or at least closed VERY slowly) 100% of the time when accessing data on the server (regardless of if a statement was opened or not)
- Financial reporter closed very quickly when the data was run on either a local workstation drive or mine workstation in my office
- task manager showed activity for the financial reporter during the extended closes.

Time to ask their "network guy" why that NIC is running at only 100Mbps.

Also check their OpLocks settings and try running from another workstation where the network speed is better. There's a hardware/configuration problem.

Aren't they complaining about other performance issues on that workstation?

Inconsistent info here..
1) If the financial reporter is opened and immediately closed with no statement actually being opened, the financial reporter closes quickly and without a problem
2) Financial reporter froze (or at least closed VERY slowly) 100% of the time when accessing data on the server (regardless of if a statement was opened or not)

Does other computers on their network exhibit the same problem?

In any case I would suggest they get rid of the XP machine and get their network running at 1 GIG not 100 Mbps.

Hi Andrew
I have also had issues with FinReporter not closing without error for a few months. Under the advice of my local Adagio rep I have tried many different scenarios to troubleshoot:

First Round:
- In ledger I tried going to FILE->USER PREFERENCES to reverse the “Save Windows Position” and “Save Window Size settings”.
- In FinReporter I went to VIEW->CUSTOMIZE and reset each of the toolbars and views.
- In Ledger went to FILE->USER PREFERENCES and turned the “Save Windows Position” and “Save Window Size settings” on (tick the boxes).
- I opened the FinReporter and then sized the window really small, closed the FR with the X. There was no other dialogue window opening in the background.

Does it do it on another workstation? YES
Does it do it with another log in name? YES

Second Round:
He suggested I copy my GL data to my desktop. Did so and FR shutdown without error when:
- I did not open any reports
- I opened reports and closed them individually before shutting the FR
- I opened a report & shutdown FR without closing reports individually (either using the 'x' or File - Close)

I have 3 sets of company books on the same network drive and this error issues is only happening when accessing this one particular set of data.

What could be causing this problem on the server for anyone trying to access one set of GL books only?

Thanks in advance, Sadie

If the Financial Reporter is having problems on Opening/Closing and the GLATREE.??? ( ??? being your data selector ) is gretaer than 200K bytes or so then delete the file.

In fact it is always safe to delete the GLATREE file as it will be recreated with the default settings when you open the Financial Reporter.

GLATREE contains the information shown in View | Accoubt Data or CTRL+F when in the Financial Reporter

Hello everyone, I did exactly that - I removed the GLATREE file from my data set and I no longer had any issues closing the Financial Reporter, whether I have reports opened or not it closed quickly and without error.

thank you Michael!!