Eliminating Every Bug
Manifold has a zero tolerance policy on bugs. Please send in bug reports if the product does not perform as described in the user documentation. SQL for ArcGIS® Pro updates include bug fixes that have been prompted by user reports. Every bug report helps make SQL for ArcGIS Pro better for you.
New bugs in the software are very rare and are very hard to find. Most bug reports, especially those filed by beginners, are not traced to real bugs but instead arise from errors in concept or operation. That's OK. The Manifold team would rather receive and review all bug reports to make sure that no real bug gets overlooked.
Minor typographic errors in user documentation are not rare. The Manifold team would like to eliminate all those as well so please send in any reports of typos.
The following guidelines will help increase identification of real bugs and will help users choose whether messages they would like to send should be sent in as suggestions, as bug reports or as requests for technical support.
Bug Report, Suggestion or Tech Support Question?
If the product does not do something as it is explicitly documented in the User Manual, that's a bug. If it does not include a feature or capability you would like to see, or if it is missing opportunities for additions here or there that might expand the usage of an existing feature, or if it does something in a way not to your liking, that's a new feature suggestion. For tips on sending in effective suggestions, please see the Suggestions page. Manifold encourages users to send in all suggestions, large or small.
Bug reports do not contain questions. If you have a question on any matter, that's a tech support question. See the Support page and the Contacting Tech Support page for information on getting tech support questions answered.
Please Note: Any email message sent in as a bug report that contains a question will get routed by heuristics to the technical support incident processing system. Please do not ask rhetorical questions or use the question mark "?" character in a bug report. If you would like a reply to a bug report, such as confirmation whether it is really a bug or not, please include an appropriate tech support token.
Quick Checklist for Bug Reports
Finding a bug is like finding a needle in a haystack. That process can go more efficiently if bug reports provide enough information to identify and eliminate bugs. Some basics:
- Please write in English and use a subject line that includes the words "SQL for ArcGIS Pro" and "bug report" to assure your email will not accidentally be intercepted by spam filters enroute. Please include the phrase "No reply expected" somewhere in your email to make it clear you do not wish to ask a tech support question.
- If reporting an error in the documentation, please report the topic in which the error occurs and quote the text that is in error.
- Describe your hardware: What processor, how much RAM in the system, how much disk total and how much free disk space? Are you physically present at the machine or are you remotely accessing the machine from somewhere else?
- Describe your software: Are you using any virtualization software? What version of Windows? What version of ArcGIS Pro? 32-bit or 64-bit SQL for ArcGIS Pro? What is the SQL for ArcGIS Pro version number reported in Help - About?
- If you are not using the very latest SQL for ArcGIS Pro update from the Updates page, please download and install the latest update and verify the bug still exists. If so, submit the bug report using the latest update. Bug reports for releases other than the very latest update cannot be investigated.
- Give a detailed description of the problem, including your workflow. Describe every dialog you used and the settings used. If you had a problem after importing some data set, what were the steps you followed? What dialogs were used and what were the settings?
- Describe the data set you used. If you can reproduce the bug (ideal!) using a data set that can be downloaded from the manifold.net web site, what is the URL to the data set and what are the steps to reproduce the problem?
- Please use ordinary text format for your email, not HTML email, and write all of your bug report in the ordinary text. Do not use attachments except for small (2 MB or less) Manifold .map files. Please do not attach .doc, .pdf or other files containing text. If a sample file is requested, Tech Support will provide upload instructions to upload the files by FTP.
- Please email bug reports to email@example.com. Do not cc your communication with tech support with any other email address.
Tips for Effective Bug Reports
Some tips on how to contribute productive bug reports that will improve the product as rapidly as you would like:
- Don't ask rhetorical questions. Bug reports should not assume replies so don't make the intake process try to guess when you are seriously asking a question and should be passed to tech support or when a question is just a rhetorical question to which you don't expect a reply.
- Do not combine tech support questions with bug reports. If you have business with tech support, take care of that in an email thread dedicated to that business. If you have a bug report, take a moment to compose a separate email message so your report will not be confused with a tech support transaction.
- Don't call a suggestion for a new feature a "bug report." For example, comments of the form "I've found a terrible bug in SQL for ArcGIS Pro - it doesn't include a full-featured word processor like Microsoft Word" are a good way to lose credibility. If you want something new, send it in as a suggestion: Have faith that a clear suggestion saying what you want will have impact. For tips, see the Suggestions page.
- Don't join a herd: if you don't have direct, personal experience of a problem don't report something you've heard on Internet. Second hand reports reduce credibility and increase noise that makes it harder to find those rare bugs that are real.
- Please provide all necessary information in your bug report. Don't refer to Internet threads or the comments of other people, as those may have changed or may not be clear. Engineers will not attempt to parse a discussion thread to guess what might be the problem - if it is a real problem they know from long experience it will be reported.
- If you are new to the product, don't jump to the assumption that something unexpected is a bug. Research the documentation carefully. Take a moment to talk out your ideas with friends, perhaps by posting to the SQL for ArcGIS Pro community forum at https://georeference.org to see if you've missed something already in SQL for ArcGIS Pro. If some preliminary exploration shows the problem might be a real bug, please send it in.
- Don't worry about looking dumb or missing something obvious in the user manual. Please don't hesitate: send in a bug report. Everybody knows most bug reports aren't really bugs. That's OK. At a minimum, your report may indicate the need to improve documentation in that subject. If you've overlooked something - no harm done. All reports are received with gratitude for the time you spend sending them in.
Ground Rules for Bug Reports
Please email bug reports to firstname.lastname@example.org. Bug reports will be acknowledged but will not usually receive a personalized reply. However, all letters conforming to the guidelines in this page are noted and will be investigated for potential bugs. In addition to the above basic tips there are several general rules which apply:
- Please keep it technical. The mission is building a better software package for the user community and that has to do with specific technical features. Focus on writing a clear and detailed technical bug report in a purely objective technical manner. Non-technical comments, earnest flames, political rhetoric, etc., will only interfere with the investigation of a bug report.
- Do not send any bug report, suggestion or comment that you do not wish to become a part of the public domain, that is, freely usable by anyone without any control by you or compensation to you. If you work for someone else, do not send any bug reports, ideas, information or suggestions that do not belong to you or that are not already in the public domain.
- Not all bug reports will receive personalized replies, but at times you may be contacted by Manifold personnel to discuss your bug report. If so, any such communications are not a guarantee that your bug report indicates a real bug or that corrective action will be taken or when such action might be taken. Do not base your purchase of licenses on an expectation that any changes may be made to the product based upon a bug report you have submitted.
Frequently Asked Questions
Does sending a bug report count as a support incident? Not unless it is embedded within a support request or if a reply is requested. Example: "How do I sort a table using a text field in the sort order I desire? Is this a bug I can't do it?" This will be treated as a request for support and will require a support token.
What if my continued use of SQL for ArcGIS Pro is dependent upon the fix of a bug I have reported? You should never acquire licenses based on anything other than the capabilities of the released product. A corollary to that is you should never acquire licenses based on anything than the usage your skill level, time and resources can get out of the product.
How do I find out the status of a bug report? Once a bug report is made there is no way to tell the status until it appears in an update to an existing release or in a new release. Manifold is grateful for all bug reports but is unable to provide reports of whether or not specific bug reports have resulted in a new bug and if so, when a fix may appear in the product. Tech support will often acknowledge the finding of a new bug with the original reporter, but that may not be possible in all cases. If you need a report for sure of the result of a bug report investigation, submit the bug report as a request for tech support with the appropriate token.
Why are not bug reports on the online user community forum monitored? There are two main reasons. The first is that this policy reserves for the forum the freedom of having informal conversations and "thinking out loud" before sending in a bug report. Experienced users like to consult with their colleagues and want to be able to discuss an issue casually without triggering an engineering investigation. The other main reason is that much speculation on Internet forums is woefully inaccurate. People take more care when composing a real bug report, so those reports judged important enough by users to send in as a bug report provide far higher quality.
The forum is very important to zero in on real bugs: New users can learn from more experienced users via online communities, and that helps improve the signal to noise ratio of bug reports. Discussing unexpected results in the forum is a good way for new users to benefit from the knowledge of their more experienced colleagues.
Advice from Technical Support
As much as bug reports are appreciated, users should not let the consideration of a possible bug lead them astray if they have encountered a problem. Few things are as effective at stopping the solutions process as deciding too early on that the problem must be a bug. Do not allow assumptions about a possible bug to prevent you from taking effective measures to solve problems.
Bugs are very rare. It is almost always a mistake to think that a problem arises from a bug and not from an error in concept or operation. If you have a problem, hit the books and apply your maximum RTFM skills. Beginners will at times leap to the conclusion that the problem they are experiencing is caused by a bug in SQL for ArcGIS Pro. Anecdotal evidence indicates that the less carefully someone has read the documentation, the more likely they are to leap to such a conclusion. This is almost always a mistake, as bugs in SQL for ArcGIS Pro are very rare and are almost never found by inexperienced users.
If you have a problem, focus your energy on a detailed understanding of what you would like to do and on a very diligent and detailed reading of the User Manual topics that are relevant. If you need assistance, don't hesitate to contact tech support as set forth in the Support page, but leave it up to tech support to run down the problem. The possibility of a bug is always kept in mind by tech support so leave it up to tech support to determine if a bug is the source of the problem. This even tech support cannot determine without lots of detailed information, so careful attention to what you are doing is necessary in any case.
It's true that on rare occasion there are new bugs found by beginners. If you are a beginner, don't let that rare statistic distract you from the more likely possibility of a nuance missed or some useful documentation misunderstood. Send in a report if you suspect a bug, but at the same time keep applying your RTFM skills, discussions with friends and, if need be, contacts with tech support for assistance.
Special Introductory Offer
Buy Now via the Online Store
Buy SQL for ArcGIS® Pro on the Online Store. The store is open 24 hours / seven days a week / every day of the year. Orders are processed immediately with a serial number sent out by email in seconds. Enjoy the world's best desktop spatial SQL today!
Manifold is a deep technology company creating advanced, parallel algorithms, next-level technology, and computation know-how that powers faster performance and smarter operations.
License Manifold® technology to power your company's products, or take advantage of Manifold's off-the-shelf commercial products. Jump decades ahead of your competition.
Manifold® products deliver quality, performance and value in the world's most sophisticated, most modern, and most powerful spatial products for GIS, ETL, DBMS, and Data Science. Total integration ensures ease of use, amazing speed, and unbeatably low cost of ownership. Tell your friends!