Most Manifold System users find that the Help documentation, web pages, training aids and participation in Internet forums amply serve their needs for understanding and support. For those users who want direct technical support by manifold.net staff, technical support products are offered for sale by manifold.net, including options for email technical support as well as voice telephone support.
License fees paid for Manifold System do not normally include technical support. Although manifold.net may provide technical support (including Service Packs or some limited number of support incidents, typically two per license) at no charge on a voluntary basis, the voluntary provision of technical support is not a commitment by manifold.net to continue to provide technical support free of charge. Normally, any free incidents that are provided as part of a license are standard tech support incidents that cover installation and interactive features only. Standard support incidents do not cover developer level features such as scripting, programming, customization, IMS, Enterprise Edition features, SQL and any question involving Runtime licenses.
To learn about technical support products or services (either paid or free) that might currently be available for Manifold System, please visit the Support page at www.manifold.net - this page will always be updated with the latest technical support information for Manifold System. Information and procedures published in the Support page on the website supersede this topic.
Regardless of how you acquired your Manifold System license or what technical support arrangements you have made, the Manifold team always appreciates receiving direct email with bug reports, comments, or suggestions for product enhancements. For tips on making suggestions that will rapidly influence the product design process, please see the Contacting manifold.net topic. To avoid spending a support incident, make sure that any such suggestions or reports clearly indicate that you do not want a reply.
Very Important: Please do not send any proprietary information or suggestions in which you or any one else claim any intellectual property interest. Please only send information or suggestions that are in the public domain.
Free Support Resources
The fastest way to get technical support is to not need it in the first place. The following resources are free to all users:
· Search this documentation thoroughly before trying alternative routes to support. Most requests for technical support are answered with a one-line email citing the relevant topic in this documentation.
· Read the Troubleshooting topics.
· Check the Support page at www.manifold.net to see if any routine updates for Manifold System have been released. If so, download and install the latest update. Updates add new features and repair bugs. New features will often remove limitations or otherwise make the system easier to use.
· Visit pages at the manifold.net website that give examples of customization (.xml files, for example), scripting within Manifold, programming in third party applications, web site creation and so on.
· At the www.manifold.net website, visit the Support page to consult the Support FAQ and other free resources.
· Participate in the Manifold System user community online forum at the GeoReference forum, especially if you are engaged in scripting or other advanced uses of Manifold. See the Help - Manifold on the Web topic for fast access to the Manifold online community and other resources. See the Support page on the Manifold web site for links to other online user communities.
· As always, Internet links can change overnight. If you can't find the above forums or links, see the Support page for current information.
Note that posting a question to an online user community such as the GeoReference forum is not the same as communicating directly with manifold.net technical support or sales personnel. If you wish to report a bug, make a suggestion or request technical support, contact manifold.net directly.
Do Not Waste Support Incidents
With the exception of initial installation and activation questions, any question sent to technical support or any question of a technical nature, however trivial, sent to other manifold.net addresses will cost an incident.
While it is entirely up to the user what questions he or she wishes to ask of technical support, the advice of the tech support staff is to avoid wasting technical support incidents on utterly trivial questions that are easily found in the documentation or other free resources. Most questions sent to technical support are elementary questions already answered in Help, the Support page or other manifold.net web pages or on free Internet resources such as the GeoReference forum. The wise user will avoid wasting support incidents on easily-found information.
See the Help - Manifold on the Web topic for fast access to the Manifold online community and other resources.
All Support Questions are Routed to Tech Support
Tech support incidents also apply to all questions of a technical support nature that are sent to sales or to any other manifold.net email address. (Some users occasionally try to gain additional incidents by sending email of a technical support nature to sales. Such emails are forwarded to tech support.) This policy applies to all questions, no matter how trivial or sophisticated. Do not waste support incidents by sending simple technical questions to sales or other manifold.net email addresses. Instead, take a moment to search and read Help.
Some manifold.net staffers participate in various Internet forums. All such participation is voluntary and is done on the employee's own time, not on company time. If you obtain the email address of a manifold.net employee, please do not use that address to send questions of a technical support nature to that employee. All such questions will be routed to tech support and a tech support incident will be required. This policy is intended to protect the individual privacy of manifold.net employees and to preserve the ability of staffers to participate in public forums without risking abuse from unfairly directed tech support questions.
Using Support Incidents / Tokens
If you have received some limited number of support incidents as part of your purchase, visit the Support page at the web site to learn how to request technical support .
Tech support can only be obtained by using technical support tokens. A token is like a serial number, a sequence of letters and numbers that uniquely identifies the rights to one technical support incident. Tokens are available for standard support incidents and for developer support incidents. Tech support inquiries (regardless of which manifold.net email address they are sent to) unaccompanied by an unused technical support token will not receive technical support.
There are two ways to get technical support tokens:
· You may receive some number, usually two, free tokens as part of acquiring a Manifold license.
· You may purchase technical support tokens. Purchasing a technical support project provides you with tech support tokens of the number and class you have purchased.
Keep your tokens confidential. Whoever has possession of a valid token can use it for tech support. If someone else obtains a support token from you they can use it to get support and thereafter that token will be used up - you will not be able to use it.
To use a support token, write to firstname.lastname@example.org with the token included in the first few lines of your email. Include that token in any further email exchanges related to that incident. For example, if tech support asks any questions that require a reply from you, include the token in your reply. A convenient way to do so is to simply include the body of previous email exchanges in the text body of your reply.
Do not use attachments or HTML email. Any attachments will be stripped out for security reasons, and HTML email will be converted to text email.
General Guidelines for Contacting manifold.net
Very important: When emailing manifold.net, to avoid having your email deleted by anti-spam software, do not attach any files, cc any third party, or send emails that have blank subject lines, blank "from" fields or almost blank subject lines such as "Re: " with no other subject text. We suggest using a subject line that clearly identifies your email as a matter that involves manifold.net or Manifold System.
Do not use obscenities or words commonly found in spam, such as references to drugs or other off-topic matters. This will avoid having your email deleted by automatic spam filters.
When interacting with manifold.net, please observe the following:
· Please include all of your comments within the email. Do not attach .doc, .pdf or other files containing text. Do not send images unless requested.
· Please do not attach any files to emails sent to tech support. If a sample file is requested, tech Support will provide upload instructions to upload the files by FTP.
· Do not contact technical support unless your system is up to date with the latest Manifold edition, the latest Manifold update, all current Windows service packs and other Microsoft updates.
· Please respond promptly to tech support emails. Incidents inactive or involving tech support questions that are left unanswered for seven days will be closed. Re-opening the matter later will cost another incident.
· Please answer all questions asked by tech support. If you do not answer all questions the incident will terminate. Re-opening the matter later will cost another incident.
· Keep in mind that there are many engineers at manifold.net, so the person who replies to some subsequent exchange in a thread might not be the same person with whom you initially corresponded. That's why it is a good idea to preserve the entire thread within any reply you make.
Please follow the above guidelines to avoid wasting tech support incidents. Tech support can help you rapidly if you provide full information and promptly answer all questions.
Runtime licenses are provided with no bundled support incidents. Any questions involving a Runtime license require a developer support incident. If you plan on using a Runtime license and deploying it to a different user, plan on providing any support that user requires.
Keep Up to Date
Do not contact technical support unless you have:
· Installed the latest release of Manifold and the latest update for that Manifold release.
· Assured your computer system fulfills all hardware and software requirements set forth in the Requirements web page for your edition of Manifold.
· Installed the latest Windows service pack for your version of Windows.
· Installed the latest Jet 4 service pack.
· Installed IE 6.0 or greater.
· Installed the latest drivers for your video card and printer if these are involved.
Manifold uses many Microsoft system resources. If there is a bug in Microsoft code, it could cause problems within Manifold. Microsoft has a continuous program of identifying and fixing any bugs in Windows or other Microsoft components through service packs. In addition, Manifold service packs will fix bugs that are discovered within Manifold.
Therefore, a condition of using tech support (to avoid wasting tech support resources on problems that have already been fixed) is that you must have the latest Manifold release and update installed. You must also have the latest Microsoft service packs for your version of Windows, for IE and for Jet 4 installed. You must have IE 6.0 or greater installed as well.
Tech Support Offered Only for Current Release
Tech support is available only for the most recent release and the most recent update of Manifold System. If a new release of Manifold System is announced make sure to upgrade to the new release if you would like to use technical support incidents. An important part of every update and new release is the correction of bugs found in previous releases. Having the most recent release and update of Manifold installed avoids any time wasted on the consideration of bugs that have long been fixed. It also avoids confusion raised by old methods that have been superseded by newer and better ways of operating Manifold.
Whenever a new release of Manifold System is announced, licensees of the previous release have traditionally been offered an upgrade for a nominal fee for a limited time (usually 45 days after publication of a new release). After that, the fee for upgrading could be considerably higher so don't miss the opportunity to upgrade to the new release when it comes out.
It is especially important to upgrade to a new release if you have procured technical support products such as a ten-incident support product. Any unused tokens from the previous release of Manifold will be wasted if you do not upgrade to the most recent release. It makes most sense to take advantage of the initial, nominal cost, upgrade offer when it comes out.
If you actively use Manifold, by default Manifold itself will notify you when a new update (including new release) has been published. If you are not actively using Manifold, make sure to check into the manifold.net web site from time to time for news of new updates and new releases.
Do Not CC Third Parties
When writing to tech support, do not "cc" third parties. Manifold.net tech support does not respond to emails that are shared with third parties or are cc'd to any other recipient, including postings on newsgroups. There are three reasons for this policy.
· The first reason is financial: A tech support incident is a valuable service provided to a single individual. It is not offered to multiple individuals at the same time.
· The second reason is practical: Experience shows that users will puff up their expertise and are less willing to admit dumb actions when an exchange takes place in front of third parties. To avoid any incentive not to be completely honest all tech support exchanges must occur in private.
Support questions that are cc'd to third parties may end up wasting any tokens used.
Contacting Technical Support using a Token
Tokens are long alphanumeric strings that are sent to you when you purchase technical support incidents, like the following:
If your email viewing program uses a narrow window, when you read the email that sends you your tech support tokens you may see the a token as "wrapped" to appear on more than one line. There are no paragraph breaks or "end of line" characters in a tech support token: it all consists of letters and numbers on a single line.
When using a technical support token, provide it exactly as sent to you. Do not change upper case to lower case, add or delete any numbers or letters or hyphens. Do not change it in any way. To avoid confusion between digits such as zero and the letter "O", it is wise to use Copy and Paste to copy the tech support token from the email in which it was sent and then to paste it into the email you are writing to tech support.
If you have a valid, unused tech support token you may contact manifold.net technical support by sending an email to email@example.com - You must include a valid, unused technical support token in the first few lines of your email message. The example below shows the beginning of an email letter to tech support that begins with a token on the first line and then continues with the letter:
Dear Tech Support,
I am using 8 pro (18.104.22.1684) on WinXP Pro SP3 running on a Dell Latitude 1300 laptop with a Core 2 Duo, 2GB of RAM, 60GB of disk with 25GB free space. When I open a map window that contains a drawing layer (it can be any drawing, like the example Mexico drawing on the download site) and then choose File - Export - Drawing the only choices I see in the Save as type box in the Export Drawing dialog are DXF files or KML / KMZ files. How do I export to shapefiles?
Technical support and the email 'bots that automatically scan all emails to tech support know a token when they see one, so there is no need to add descriptive text such as "I'd like to use the following token" or other comments. Simply placing your valid, unused technical support token in the first few lines of the email message is enough.
Include the token in any subsequent emails in that thread. This is easily done if you get in the habit of including all previous exchanges in the body of any response.
If you ask a question that requires a developer support token (any questions on programming, scripting, SQL, Enterprise Edition, web serving, any customization of any kind) you must provide a developer level support token. A free token for standard technical support will not suffice.
If you do not have a technical support token, you cannot use manifold.net tech support. If you send an email to technical support without including a valid, unused technical support token in the first few lines of the email message, you receive a form letter reply indicating the need for tech support tokens. If you use a token that has already been used up, you will receive a form letter stating the token you used has already been used up.
If you send an email asking questions of a technical nature to any other manifold.net email address it will be routed to technical support. Folks who repeatedly write with technical questions to other manifold.net email addresses (such as sales) will have whatever tokens they have available used up, and could end up being barred from manifold.net email systems.
Information Required when Contacting Tech Support
Any request for technical support must include, at a minimum, the information technical support may need to service the request. Such information must include:
A valid, unused technical support token.
· The specific manifold.net product you are using with build number from the Help - About dialog.
· The exact Windows version in use and the Windows service pack applied.
· The exact version and name of any Windows emulator, virtual machine or any other operating system modification, if in use.
· The brand of personal computer you are using (or motherboard).
· The processor you are using.
· The amount of RAM installed in your system.
· The total amount of disk space installed in your system and the total amount of free disk space.
· A description of the problem.
· A description of the data set or map you were using.
· Very Important: If you can do so, provide a specific sequence of actions that reproduce the problem using only maps or data sets from the Manifold CD.
Submitting a request for tech support without the above information will delay assistance until the required information can be obtained. See the example above.
Tech tip: The answer in the above example is to open the drawing in its own window to be able to export to the full list of formats to which drawings may be exported. Alternately, right click on the drawing in the project pane and choose Export. Maps have layers, so when opening a map window and choosing File - Export the map can only be exported to those drawing formats available for export that work with multiple layers, such as DXF or KML / KMZ.
Checking Status of Tech Support Tokens and Serial Numbers
To check the status of any particular technical support token or Manifold serial number, visit the Support page on the www.manifold.net web site to find a link to the Serial Number Status page. The status page may be used to find out if a particular technical support token has already been used.
The status page also may be used to find out if a particular serial number is a 32-bit or 64-bit serial number, whether it is still active or has been revoked (as might occur if it has been traded in for an upgrade), what product it authorizes and how many Activation keys are available.
A reminder: Any use of a serial number or technical support token, such as checking status via the Serial Number Status page, should be done using Copy and Paste from the original serial number email sent out by manifold.net.
When checking the status of Manifold serial numbers, do not use the "masked" version of the serial number that may be displayed in the Help - About dialog which ends in a series of X characters. The masked version displayed in Help - About has had the final characters altered with a series of X characters so that someone who has physical access to your computer cannot steal your Manifold serial number. The masked version displays enough of the serial number so you can determine for your internal record keeping which serial number you used on a particular machine, but not enough of the serial number for someone to be able to steal it and use it to obtain Activation keys or other wise use it.
User reports are a key aspect of identifying, tracking down, and annihilating bugs. The most important requirement for this process is the ability to reproduce a reported bug in the lab. Therefore, we ask that any bug reports (if at all possible) include a specific sequence of steps that will reproduce the bug when applied to a data set that is provided on the Manifold download site. Please make sure you have installed the latest Service Pack and have verified the bug still exists before submitting a bug report.
Bug reports are not considered incidents if you do not request a reply. If you wish to report a bug, send an email of any length; however, make it clear you do not require a reply. For example, begin your letter with "Bug report - no reply necessary."
Users will at times send in a bug report and then ask that the bug report be confirmed or denied as a known bug. This is counted as a tech support incident because the user is asking for a custom report of bug status. Most bug reports (well over 95%) do not identify a new bug. Instead, they are errors arising from failure to read the documentation, the FAQ, the Knowledge Base or otherwise are errors of concept or operation. True bugs are very rare.
When a bug report is received it goes into a queue for examination. If it is found upon investigation to be a real bug it gets fixed and eventually appears as a bug fix in an update. Publication of the update is notification of the bug. Updates are published so frequently that it is faster to simply eliminate a bug than to note it on a web page. If you want a custom response as to whether what you think is a bug really is or is not a bug,that requires usage of a tech support incident.
If you do submit a bug report and do not request a reply, Tech Support may contact you as part of their investigation. If so, that does not count as an incident. See the manifold.net web site's Support pages for additional information on bug reports.
Corrections of errata are made through Updates (formerly called Service Packs), which may be downloaded by authorized users from Manifold web sites. Manifold releases from 7x onward will by default advise you when launched if a new update is available. The latest update automatically includes all fixes and upgrades issued in previous updates.
How to Avoid Needing Technical Support
The good news is that answers to most technical support incidents are really simply answers, so simple that users are often embarrassed by how obvious the answer was. That's OK, as it is human nature to sometimes overlook the obvious. The key with technical software like Manifold is to leverage the strong part of human nature, the ability to understand and apply cool new things, by having and applying an adult expectation of the effort required to master those cool new things. That means carefully reading documentation and taking advantage of the many resources on the web and in literature for self-education.
If you read documentation and instructions carefully you will eliminate the need to use technical support in most situations. A very high percentage, over 95%, of tech support incidents are used to ask questions for which the answers may be very easily found in the documentation or installation instructions for Manifold.
An astonishingly high percentage, perhaps 30%, of support incidents involve a letter from a user such as "I have read the ... topic but I don't see the answer to this question" even though the topic includes an obvious answer to that question. Why this happens has been researched, as people usually do not want to waste their time writing to tech support if they have the answer immediately at hand.
Initial results indicate that when some people are in a hurry to find the answer to an important question they speed up their review of documentation to the point that they no longer actually read it. Instead, they skim it quickly. If they are in a big hurry they might skim documentation so quickly they miss even glaringly obvious answers, such as those highlighted with bright red, boldfaced "Important" markers.
The solution to this is to slow down, take your time and read the documentation carefully. If you find yourself uncontrollably skimming documentation and unable to actually read it, try reading out loud. This will force you to slow down and actually read each word.
This is especially important if you are attempting a complex project under a lot of time pressure and have encountered difficulties. When people rush through debugging they are never sure whether or not in their haste they have really checked some possibility, so they go back and check it again and again. This is a terrible waste of time. It's like a person who has lost his or her car keys and in great haste starts going through the pockets of clothing they have worn recently. Some people get into a panic and find themselves going through the same pockets over and over "to be sure."
A better method is not to panic. Slow down. Debug what you are doing systematically. Write down a list of possibilities and check each one carefully and systematically. Consult the documentation on each point and read each relevant topic slowly and very carefully, thinking about what that topic teaches and how it may relate to the task at hand. Keep careful notes on what you have done and the settings you used for various dialogs so that if you ever do decide to contact technical support you can provide an exactly accurate and detailed description of what you have done. Quite often, just the act of writing a detailed account of what you have done will reveal an error.
Invest in Education - People who invest in their own education by reading the documentation, discussing issues with other Manifold users in the online community and investing into education via training products or coursework in schools will almost never require technical support. If your time is valuable (whose time is not valuable?) it is worth your while to invest into your own education through training.
Many third parties provide training for Manifold System. The training products sold at http://www.gisadvisor.com have been especially praised by Manifold users in online forums. Many users report that self-paced training products like those sold by GISadvisor.com are an easier path to learning than relying exclusively upon reading documentation.
Bugs are Very Rare - Newbies will at times leap to the conclusion that the problem they are experiencing is caused by a bug in Manifold. 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 Manifold are very rare and are almost never found by inexperienced users.
It is usually a waste of time and energy to think that whatever problem you are experiencing is caused by a bug in Manifold. That is almost always a psychological drain that will divert your attention from successfully understanding what is going on. Instead, focus your energy on a detailed understanding of what you would like to do and the Help topics that are relevant. The possibility of a bug is always kept in mind by tech support, but 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 just as "even a broken clock is accurate twice a day" on very rare occasion there are new bugs found as a matter of happenstance by beginners. Don't let that rare statistic distract you from starting your analysis by assuming you have missed something in the documentation.
You can, of course, submit a bug report following the guidelines in this topic even if you are not sure that something is a bug or not. Manifold gratefully receives thousands of bug reports knowing full well that almost all of them are not bugs. But all are gratefully received so that even if only one small bug is found by sifting through many reports the system will become better than it is. Collecting and acting upon many bug reports is one reason the system has become so clean that new bugs are very rare, and that's the way everyone wants to keep it. Just don't allow the writing of a bug report to distract you from the more likely possibility of a nuance missed or misunderstood.
In a related note, beginners uncertain of their skills will sometimes panic after reading Internet forum threads discussing "bugs" in Manifold. Almost all "bugs" discussed in Internet forums on Manifold are not bugs. There are a few, of course, that experts discuss; however, most postings that include the word "bug" in the subject line do not discuss bugs but rather end up being a discussion of something the original poster did not understand.
This is such a common effect that the use of the word "bug" in a subject line tends to indicate the poster is either a rank beginner or is easily panicked, as Manifold experts know that new bugs are very rare and whatever problem they are experiencing most likely derives from some fine point that is yet to be learned or has been missed. So they don't normally post using that word in the subject line. Instead, they post using a subject line that describes unidentified behavior as narrowly and neutrally as possible. The last thing an expert wants is to be embarrassed by calling something a "bug" only to learn that it was a simple error on his or her part, so experts tend to avoid that word.
In contrast, beginners will at times launch a thread on some awful "bug" they have discovered when they have simply neglected to learn and apply the software properly. On occasion some people persist in insisting something is a bug even after numerous experts have responded to their post pointing out the problem is not a bug. But still the thread persists using the word "bug" in the subject and that can scare other beginners as yet uncertain of their own mastery of the software. Don't let that bug you!
See the Support page on the manifold.net web site for frequently asked questions, Knowledge Base articles discussing what is or is not a tech support incident and other useful information about using technical support.
Why do you charge an incident for even simple questions? There is no way to foretell if a particular email received from a user is a trivial question or a sophisticated question. Each question requires reading by a trained engineer to assure that a sophisticated question that might appear to be a simple question to the untrained eye is properly answered.
For that reason, it costs as much to process an apparently trivial question as it does a carefully thought-out, complex question. In fact, some classes of trivial questions require more effort because users neglect to provide required information or because through lack of experience the user might think something is far simpler than it really is.
Ultimately, since questions must be processed by talented engineers what an incident really covers is the time spent by that engineer together with associated support costs. It doesn't matter if someone is using up that engineer's time with a brilliant question, or if that engineer's time is used up suggesting the customer read a web page, like the Support page, for material that is explicitly discussed on that page.
Why do you ask for so much information? Long experience shows that having all required information at hand is the fastest way of resolving a tech support problem. If Tech Support must repeatedly ask that necessary information be provided, a technical support incident will be charged. For example, tech support questions of the form "I can't open the file - what am I doing wrong?" are a good way to waste incidents. Tech Support must respond by first asking for all information noted as set forth in the Support page on the manifold.net website. Only after that information is provided can Tech Support help the user.
Most tech support questions are very elementary errors or misconceptions. Even the smartest people can miss something very simple, so it is essential in Tech Support that the details be nailed down. Getting the background information is essential to getting the details right.
Some users will not cooperate with Technical Support. The classic case is a user who "knows" his problem is not something dumb he is doing so he refuses to answer questions asked by Tech Support that he feels are demeaning. However, when tech support asks simple questions it is based on long experience that shows even the smartest people will at times make really dumb mistakes that may be obvious to a third party but not to the person struggling with the problem. Such mistakes must be excluded by asking specific questions and getting clear answers, with nothing taken for granted. If a user does not answer all of Tech Support's questions the incident will be closed (and charged to the user).
Why must I have the latest versions of everything and the latest service packs? Manifold uses many Microsoft system facilities to assure perfect compatibility with Windows. Problems within Microsoft code might therefore show themselves as problems encountered when running Manifold. Both Manifold and Microsoft eliminate problems by issuing service packs and by issuing newer releases. Because technical support is a limited resource, it does not make sense to waste it on figuring out and fixing problems that have already been fixed by either Manifold or Microsoft in a service pack or in a new release. Requiring that customers use the latest release of Manifold and install the latest Manifold and Microsoft service packs is the only way to guarantee that problems that have already been fixed are not at issue.
Can I get free tech support by sending a question to Sales? Tech support incidents also apply to questions of a technical support nature that are sent to sales or to any other manifold.net email address. Some users occasionally try to gain additional incidents by sending email that is clearly of a technical support nature to sales or to other manifold.net email addresses. Such emails are forwarded to tech support and will be charged as tech support incidents.
Can I ask more than one question in the same email? When more than one question is asked in the same email, Technical Support will apply an incident to each question in turn until the user runs out of incidents. An incident covers the lowest resolvable usage in Manifold, so any distinctly different questions involve different incidents. For example, a question as to why certain fields are not being transferred may be answered by Technical Support with a note to use Transfer Rules. That's one question with one answer and one incident. A follow-up question by the user asking how to set transfer rules to a particular default setting is a second question that will consume a second incident.
Does tech support assume I've read the documentation? It is unrealistic to assume that someone is attempting to use Manifold without reading the documentation. All tech support interactions proceed based on the assumption that users are in fact reading the documentation. Answers to questions therefore assume that users will use those answers as a guide to reading Help. For example, a technical support answer that cites the need to use Transfer Rules assumes that the user will read the Transfer Rules topic in Help as well as other relevant topics that branch out from that topic.
Technical support answers are therefore not a substitute for reading the documentation. If any information is available in Help, technical support will not repeat it but will assume the user will read such documentation based upon the notes in the technical support reply. Since individual subjects will often branch out from one topic into many different topics, technical support will not enumerate all topics that might be relevant: it is assumed the user will click on hyperlinks and other references to branch out through the documentation as the user sees fit.
What does a tech support incident cover? A technical support incident is any single question asked of technical support. The same incident continues no matter how many emails are exchanged until the single question is answered. "Single questions" mean those that resolve to one function or to the lowest, single, separable usage level of Manifold in a specific task.
For example, the question "How do I use Manifold?" is indeed a single question, but it is not resolvable to one function or to a matter of a single usage level in a specific task. Asking such a general question is a waste of a support incident because it will result in an equally general answer.
General questions will receive general answers, since they usually involve numerous functions or very many lower level usage levels. For example, a general question such as "How can I link to external database tables" will receive a general answer pointing out various Manifold Help topics to read, which will cost one incident. The thread does not continue into subsequent specific questions, such as, perhaps, how to operate an ODBC dialog, how to configure one's SQL Server database system and so on.
It is possible, of course, if one purchases enough support incidents to use tech support as a replacement for reading the documentation. However, such usage is very inefficient and expensive. A better idea is to get some general education in the subject matter, to read the documentation or to hire a consultant with the required expertise.
Excluded from standard support are questions related to any form of scripting, any other programming, any customization (through any of the methods that might be used to customize Manifold, such as custom datum projection grids, geocoding data extensions, or the various other customization features), SQL, Enterprise Edition features, Manifold IMS and any question involving a Runtime license. These topics require development level support incidents.
Excluded also are questions that are of a consulting or educational nature or that describe the operation of Windows in general or products other than Manifold System. Only supported are the specific functions and capabilities of Manifold.
Examples of supported questions:
· "How do I import a projected .shp file?"
· "Can Manifold import .ijk format for surfaces?"
· "How do I rotate a label?"
· "How do I link a table into a project?"
· "If I do not have enough free space in my Windows TEMP folder, will that be a problem?"
Examples of unsupported questions:
· "What is the difference between .shp files and .mid/.mif files?"
· "How do I write a script to import .ijk format for surfaces?"
· "How are labels stored in AutoCAD?"
· "How should I configure SQL Server with the right permissions for me to link a table into my project?"
· "How do I change the location of my Windows TEMP folder?"
· "What is wrong with my XML customization?"
· "Microsoft IIS won't launch on my machine. What am I doing wrong?"
Note also that Manifold Technical Support provides technical support on Manifold products, not on Microsoft facilities or on other products. Manifold can work with many other software products. For example, one can create a linked drawing in Manifold that draws its contents from a SQL Server table. However, support on Manifold is limited to Manifold only.
For example, if you are having difficulty creating a linked drawing because your SQL Server system or Windows security is configured in a way that prevents your user login from accessing the desired SQL Server table then Manifold tech support will not undertake what is, in effect, a consulting project to help you re-configure SQL Server or diagnose the improper administrative setup of Windows.
Manifold exposes a variety of interfaces that may be used by third parties to create add-ins or other modules that work with Manifold. Manifold Technical Support does not support such third party code. For example, Manifold Technical Support does not support any add-ins from third parties, image server modules from third parties, geocoding modules from third parties or any programs utilizing Manifold runtimes.
Important: Does manifold.net support the DBMS products provided for free by DBMS vendors? No. Manifold.net does not provide any support whatsoever for installation, administration, management, configuration or use of the DBMS products provided for free by DBMS vendors.
Free packages are discussed for the convenience of users only: They are not supported by manifold.net and they are not supported by the DBMS vendors. If you want a supported DBMS installation, you must purchase a supported DBMS product from one of the DBMS vendors or you must purchase support products, if such are available, for the free DBMS product you are using from the vendor of that DBMS product. Manifold.net does not sell support products for the free DBMS products provided by DBMS vendors.
The DBMS products provided for free are each supported by a vast industry of educational and training materials. Hundreds of books, for example, have been written on SQL Server alone, ranging from texts aimed at "dummies" to those covering the most sophisticated uses imaginable. Users intending to take advantage of these DBMS products should acquire and utilize the appropriate educational materials.
Important: Do not waste technical support tokens by sending in tokens for questions about the free DBMS products. Doing so will simply waste a token to no good purpose.
Developer level support incidents may be used for questions about Enterprise Edition features used with these database products, but only for the actual Enterprise dialog. For example a question about connecting with Enterprise Edition via Database Console to an Oracle data source will result in an answer limited to the use of the Manifold dialog, such as explaining the purpose of the Server, User Name and Password boxes. Support does not extend to explaining how you can configure users in the DBMS, how to determine what server name is being used or should be used or how to determine whether a given user has connectivity to a given data source.
What do developer technical support incidents cover? As noted in the above comments, developer level incidents cover all aspects of Manifold System, including scripting, any other programming, any customization (through any of the methods that might be used to customize Manifold, such as custom datum projection grids, geocoding data extensions, or the various other customization features), SQL, Enterprise Edition features, Manifold IMS and questions involving a Runtime license.
Excluded also are questions that are of a consulting or educational nature or that describe the operation of Windows in general or products other than Manifold System. Only supported are the specific functions and capabilities of Manifold.
Note that as with standard technical support incidents, developer incidents cover a single question that relates to one function or to the lowest separable usage level of Manifold in a specific task. General questions will get a general response. Exploration of sub-parts of that general response or more specific questions for more detailed "how to" guidance on sub-parts will require additional developer incidents.
Investigation of development problems will often involve more than one technical issue, with more than one error in usage or the need for guidance in more than one area. Sometimes a sequence of problems must be identified and solved before an overall problem can be identified and cured. That will require a sequence of developer support incidents. Each problem solved, even if only for diagnostic purposes to set aside a possible cause, uses up a developer support incident.
Developers are strongly advised not to waste support incidents on simple matters that may be found in the user manual, in examples published on the manifold.net web site or that may be found in a careful search of past threads on Internet forums for Manifold System, such as forum.manifold.net. It is also a good idea to first achieve expertise in the development environment being used so that developer incidents are not wasted on matters arising from weak understanding of the target development environment.
Developers will get maximum value when using developer support incidents if they have strong skills in the development methodology that they choose. For example, if a developer does not have strong Visual Studio expertise it is easy to waste developer incidents on questions arising from generic operation of Visual Studio that have nothing specific to do with Manifold. In such cases it would be more effective to develop greater skill in Visual Studio programming using general Microsoft educational resources such as MSDN and to save developer support incidents for issues specific to Manifold. Note that Manifold developer incidents are not a support path for non-Manifold tools such as Visual Studio.
Developer incidents are not a consultation service. Although general questions of how to approach a particular task are appropriate for a developer incident (and will receive a very general answer in reply) a developer incident cannot be used as a replacement for the services of an expert consultant. Many experts provide Manifold consulting. Recruit such experts with postings on forum.manifold.net if you need a consultant.
For example, developer level incidents may help zero in on an approach to a new project. Someone might ask, "I have the following three approaches I might take and here are the pros and cons of each as I understand them. Which do you recommend?" Although the answer to such questions will be brief and general, a pointer in the right direction from a manifold.net expert will often be very valuable for the guidance it gives. If taking this approach, keep in mind that such guidance will be brief and general. Further discussion, clarifications, assistance in writing code and so on will all consume additional incidents and will not be cost-effective compared to hiring a consultant to assist in the project.
Developer incidents are not a code-writing service. At times an answer from tech support might include snippets of code to illustrate a particular point (at the option of the tech support engineer writing the response), but this only occurs in very specific matters like the functioning of a particular object in a highly specific context. Anything other than such very specific snippets consisting of one or two lines of code should not be expected. Requesting that tech support send you a code sample for a particular task will waste an incident.
The bottom line for developer incidents is that they are a good way for people who have a mature and expert understanding of Manifold interactively and also a thorough understanding of their development environment to ask specific questions about specific features. For example, when you are deep inside a programming project and have hit a specific roadblock involving a particular object, a developer level incident can work magic to part the mists of confusion and get past that roadblock.
Why don't you provide free technical support? Regrettably, there is no such thing as "free" technical support any more than there are perpetual motion machines. If there was such a thing as free technical support we would be the first to take advantage of it!
In real life it is a very expensive proposition to keep expert engineers at hand to answer technical questions. Salaries must be paid, equipment must be provided and facilities and other resources must be funded. All that money comes from somewhere, and in a commercial company that means that every dollar for any cost associated with providing technical support comes from money paid by customers. In one way or another customers pay for technical support as that is the only source of revenue in commercial companies.
The money taken from customers to pay for technical support can come from some percentage of money paid for the product or it can come from extra fees that are charged those who use technical support or it can come from some combination of the two. But no matter what it all comes from the customer. The only question is what is the most fair and efficient way to charge customers for technical support.
Those companies who say they provide "free" technical support for a product are really telling a lie, because as we have seen above the customer is paying for that technical support in some way. In the case of companies who mean by "free" that they do not charge extra for specific uses of technical support, what is really going on is that some portion of the money all customers pay to buy the product is set aside to pay for the costs of running the technical support function. If that money were not used for technical support, the product could have been sold to customers for a lower price. The technical support in such cases is not free; it is just hidden as a cost within an inflated product price.
Since most users do not use technical support while a small percentage of users will abuse "free" technical support, what ends up happening in such situations is that everyone must pay a higher price for a product just so that some people can be subsidized with extra services paid for by other people. We don't think that is fair.
Manifold.net does not burden the price of Manifold System with hidden costs because we believe that doing so would be an unfair transfer of costs from some customers to other customers. If we were to provide "free" support on Manifold System, we would have to increase the cost of the product to pay for that support.
If we were to increase the cost of the product to all users to provide "free" technical support for everyone, we would in effect be charging those users who do not need technical support to provide a special service to those who do. It is especially unfair to all customers if that special service is provided (at great cost) to those who won't read documentation or invest in their own educations because they know that others will pay for those lapses.
Even setting aside egregious abuses, what one person thinks is a fair use might not be reckoned fair by those who are called upon to pay for it. For example, a consultant who is under intense time pressure to complete a task and who does not have time to read documentation thoroughly may consider that situation "business as usual" while another user may feel that part of budgeting a project is setting aside enough time to get educated in the use of required tools. The only way to respect what everyone considers fair in such circumstances is to let everyone pay for the resources they use.
We feel the fairest system is to not charge for technical support through hidden transfers but to directly and openly charge people for whatever support they choose to use. In that way, those people who prefer to use free resources like self-education, documentation and Internet forums to answer questions are not forced to pay for those who don't, and those people who find it more expedient and efficient to pay for technical support can do so.
The reader should understand that the above comments on people who abuse "free" technical support are not intended to be disrespectful to those who use technical support in the normal way. It can make sense from time to time even for the most diligent, the best managed, the best educated and the very brightest people to seek help from technical support. It's just that we think the fairest way of running matters is that when someone does decide to use technical support (for whatever reason) that person should pay their own costs of doing so.
Help - Manifold on the Web