Monthly Archives: May 2009
Tips for Reporting Bugs to Esri
Click the “Report Software Defect” radio button
Always select the “Report a software defect” option when submitting bugs through the online form. That lets our Support Team know right away, that you’ve found a bug.
Let us know how severe the issue is
Help us understand how severe the bug you are reporting is to you and your organization. We understand that you may find bugs that are not impacting your daily workflow, or bugs that may hinder or stop your daily workflows; let us know where the bug you are reporting falls.
Include the exact steps to reproduce the problem
We appreciate you letting us know about a bug and want to get all the information right away, so you can get back to your busy day. It helps us if you include exact steps to reproduce the problem, and any other tests you have run. This way when the bug is being resolved, we fully understand your workflow and make sure it’s fixed using your steps.
Include your data
Please try to include a small sample of your data when submitting a bug. We understand you may not always be able to include data; but if you are including data, please attach it when reporting the bug. This helps us clearly understand the issue, and how it affects your workflows.
—Beth G., User Advocacy Group Program Manager, Esri Support Services
Things to consider when preparing data to send to an ESS Support Analyst
Hi, my name is Chris W. and I am a Support analyst on the ArcGIS Server Team within ESRI Support Services (ESS). ESRI Support analysts often request data, as it can offer further insight into your suspected technical issue or software defect. When a technical issue is reproducible or an error is thrown during the execution of a specific step of your workflow, supplying the ESRI Support analyst with all the information necessary to extract your data and reproduce your issue helps to expedite incident resolution.
The data that an analyst is looking for will depend on your technical issue, and there are a few things that you can do to help move the incident towards resolution. Here are some key points to keep in mind when sending data to ESS.
First and foremost, use relative paths for all data, and make the paths as simple as possible. For example, if your problem is dealing with your MXD freezing when you zoom to a certain scale, create a folder and place a copy of the data in that folder and a copy of the MXD referencing the data in the same folder. When you use relative paths, in this case, you can send the data to the analyst, they can extract it, and open the MXD and none of the data paths are broken. The analyst is ready to zoom in and see your MXD freeze. The same applies for models that are misbehaving, as well as many other situations. If, for some reason, the data paths are broken, we’ll step you through the process of correcting the paths, helping to save time and any possible frustration on your end.
Along with using relative paths, consider sending a Microsoft Word document that has screen shots of your workflow with captions to help explain the steps being taken. As Kevin mentioned in the previous blog post, a picture is worth a thousand words. If it is something as easy to understand as zooming in to a certain scale, you can forget this bit of advice, but a technical problem that requires data being sent is rarely that simple.
If you are not sure that you are sending the data correctly, send your ZIP file to another computer and extract your data. This is a great way to test your data and how it is compiled prior to sending it to an ESRI Support analyst. Likewise, we’re here to assist you and step you through the process if you are unsure how to send us your data.
Hopefully the information above helps you in helping us resolve your incidents more efficiently, and therefore contributing to your overall success with your GIS projects.
-Chris W., ArcGIS Server Support Analyst, ESRI Support Services
Does the Support analyst really care what service pack information I am using?
100% absolutely! You may have wondered why the Support analyst you work with questions what operating system, service pack, relational database, etc. you are using, when all you have is a quick question and the information seems unrelated.
Well, all these specifics are important, as these details could determine that one workflow or procedure is more suited depending on your operating system and ESRI Service Pack level. Even the smallest detail could change how we help you come to a resolution.
In addition to assisting the Support analyst and coming to a resolution, this information is collected and passed back to our development teams via reporting. They are able to look at product trends, operating systems, service pack information, and virtual machine use to help drive future enhancements and operating system support.
So, don’t be surprised if we ask you questions so that we are able to fill in the Desktop, Server, and Misc. boxes, that can be seen in the image below, on your next support call!
The image above is of the product information excerpt from the call entry form that the ESRI Support analyst uses while working on your call. This particular call entry form shows a 9.3 SP1 Desktop call that makes use of ArcIMS 9.2 SP4 with MrSID data stored in Oracle on a Virtual Machine.
Here is a link to the Service Pack Finder utility, PatchFinder93.exe: How to identify which Service Pack is installed.
-Kevin H., ArcGIS Server Group Lead, ESRI Support Services
How to Print a Large Map as Panels or Tiles with ArcPress or ArcMap
Hi, this is Cassandra with another printing tip.
When getting ready to print a very large map that will not fit on a single piece of printer paper, you need to set up ArcMap to print in tiles or panels (also sometimes called tiling or paneling). Print tiles are strips of a single map printed out with the intention of manually taping the tiles together.
The problem that can occur is that the custom printer paper size set to accommodate the map page is not large enough, resulting in more tiles printed than desired or more than seems logically necessary.
For example, I have created a map page size of 135” x 64” and I intend to print it on my HP DesignJet 4000 printer, which is loaded with 36” wide paper. This means I can print a maximum of 36” wide, but as with most modern large format printers, I can print as long as I want. So therefore, I’d like to print my map in two tiles.
135″ x 64″ map page in ArcMap 9.3 layout
After selecting my HP DesignJet 400 from the Printer drop-down list in ArcMap Page and Print Setup, I click on the Properties button to set up a custom printer paper size.
Note: For more information on setting a custom printer paper size, see knowledge base article 17833.
ArcMap Page and Print Setup
Print driver properties for the HP Designjet 4000 HPGL2/RTL
Note that print driver properties vary from printer to printer. To set up a custom paper size for this particular printer and driver, I click the Custom button, which is outlined in red in the above image.
I then enter the custom printer paper size, which should allow ArcMap to split my 135” x 64” map and print it into two tiles.
Custom Paper Sizes dialog box from the HP DesignJet 4000 HPGL2/RTL printer driver properties
After clicking OK on the Custom Paper Sizes and on the Properties dialog boxes, I select the Landscape radio button under Paper on Page and Print Setup. The paper and map page sizes in the “layout preview” area on the right hand side of Page and Print Setup look correct and it looks like my map will print in two tiles, as I expect.
However when I go to print, I see that ArcMap is prompting to print the map in four tiles, not two.
The reason why this is occurring is because we are not using ‘Use printer paper settings’. When the map page size is larger than the printer can print or the Page and Print Setup option ‘Use printer paper settings’ is not selected, the map page logic is slightly different.
Without ‘Use printer paper settings’, ArcMap prints the entire map page, in this case 135” x 64”, regardless of any “margins” I have included in my layout. All printers require some area on all four sides of each paper to feed the paper through; these are margins, which reduce the maximum printable area available on the selected paper size for an application to use. So again with this case, I have set the paper size to 36” x 135”, but in actuality, the maximum printable area of that paper size is closer to 34” x 133”. To print the entire map page of 135” x 64”, ArcMap split that last 2” of length over to the next two pages, resulting in four tiles.
See the Concept section of the following knowledge base article for more discussion on the ‘Use printer paper settings’: knowledge base article 29238.
To accommodate the printer’s minimum required margin and my map page, I need to make the printer custom paper size a bit longer. In this case, a custom printer paper size of 36” x 137” will adequately accommodate both, and ArcMap will print my large map in two tiles as desired.
-Cassandra L., Desktop Support Analyst, ESRI Support Services