Reports.dic is the Achilles' Heel of GP. I often refer to the reports.dic file as such for two reasons:
1.) The file can become easily corrupted
2.) A corrupted reports.dic file can cause mystifying application failures and error messages
The most debilitating failure is that GP will not launch. You will get Dexterity error messages, which will likely cause you to spend 1 to 3 hours troubleshooting the problem.
The reports.dic file is one of the first files that is loaded when GP is launched. If there is a problem, the launch fails. And it doesn't inform you that the reports file is the problem.
The easiest solution is to locate and rename the reports.dic file.
The complete solution is three steps:
- Export resources from the current Reports.dic file
- Rename the existing Reports.dic file
- Import resources into the new Reports.dic file
Labels: Reports.dic
posted by Steve Chapman @ Thursday, February 19, 2009
5 Comments
5 Comments:
Agreed! The dictionary files can definitely be a pain.
The other element of the custom Forms and Report dictionaries that can occasionally cause problems is when the dictionary files are shared.
I've had cases where the shared Forms and Reports dictionaries work fine on 10 out of 12 workstations, but cause bizarre errors and GP crashes on the other 2 workstations. Moving the dictionaries local has solved the problem.
My only guess so far is that the load of the large dictionary files is very sensitive to network issues, so a network drop at one workstation may be fine, while another 5 feet away may have a connectivity issue that causes problems.
Aside from that, being unable to import packages into shared dictionaries while users are in the system is a definite inconvenience.
I will often use the import button from within Report writer. You can import reports without having everyone get off the system. You need to have a seperate reports.dic file to do this. Besides the database itself, reports.dic, forms.dic etc. are the most important files to back up on a regular basis.
I agree completely. Perhaps in a future version, the reports would get stored in the SQL Database.
My answer is simple and I have been saying for years. Don't use shared Reports.dic. Use a synchronised one instead. See the article below for more info:
http://blogs.msdn.com/developingfordynamicsgp/archive/2008/08/20/automating-distribution-of-customisations-part-1.aspx
David
http://blogs.msdn.com/DevelopingForDynamicsGP/
Excellent suggestion David. I'm embarrassed to say that I never thought of that. Staring me right in the face the whole time!
Thanks for keeping us honest!
Post a Comment
<< Home