|
Some info and commentary so folks can get the most out of their support incidents... In any case, since this is something thats mentioned in the help manual, There are lots of things mentioned in the help manual that have nothing, per se, to do with Manifold, for example the numerous Microsoft facilities in the environment within which Manifold operates such as IIS, the use of various languages, specific hardware and so on. That Help offers tips from time to time on various matters outside of Manifold is not a substitute for the documentation and support resources offered by Microsoft or the various vendors of other software and hardware. When you think about it, that makes sense and is in the interest of users. For Microsoft especially there are vast, seemingly endless resources available either for free or for fee to learn just about anything you might want to know about their products down to microscopic detail. Manifold reminds folks of the above in one of the first paragraphs of the first IMS topic (Map Server Overview), and points folks at the many Windows resources out there: This topic assumes the reader is familiar with Microsoft Internet Information Server (IIS) as well as web programming using HTML and Active Server Pages (ASP or ASP .NET). Creating web sites with IIS is a straightforward process supported by a vast array of books and other educational resources. If you are not familiar with the operation of IIS, please get a good book on the subject and learn elementary IIS operation and administration before attempting to work with Manifold IMS. The IMS topics in this documentation provide some tips on working with IIS and Windows, but they are not a replacement for reading and understanding Microsoft documentation on IIS and Windows. Although the above is routinely repeated in various places there are times when operation of Manifold facilities will routinely cause questions where the explanations of what is being done exclusively within Manifold routinely will encounter some conceptual errors where users mistake the use of some Microsoft thing with whatever is going on exclusively having to do with Manifold. Classic examples are programming questions, where rather few of those are really about Manifold and instead usually involve fairly elementary errors in operating the programming language such as syntax errors. That is, they'd still be errors if the objects involved weren't Manifold objects. That is one of the two hallmarks of what gets classed as a developer incident, the other hallmark being a level of variability requiring greater expertise to figure out (brought on by "programming" or alterations with Manifold itself, for instance, customization being the classic example). If you look at what are classed as development incidents (set forth in http://www.manifold.net/tech/contacting_tech.shtml and in the Support FAQ), that's why standard incidents exclude "questions on Enterprise, Database Administrator or License Server features, geometry linked from external sources, scripting or programming, IMS or web applications, customization, runtime licenses and SQL." Even though developer incidents routinely involve conceptual matters that brush up against non-Manifold things, it is important to recall that the purpose of Manifold tech support is to answer questions about Manifold. It is not to answer questions about Microsoft or other facilities not part of Manifold. This is emphasized in the support information (such as the Support FAQ cited by the other Support pages) with passages such as 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 provide the integration consulting to help you re-configure SQL Server or diagnose the improper administrative setup of Windows. Developer support incidents tend to be far more broadly administered than standard support incidents but when they do brush up against non-Manifold things the main purpose of them is to draw that firewall between genuinely Manifold things and non-Manifold things so that the Manifold thing can be answered and, if it is not a Manifold thing at all, so that the user can be informed it is not a Manifold thing. In that latter case the value of the information is pointing the user in the right direction and that is what the fee is being paid for. Let's use this thread as an example case to apply the above information on whether it makes sense to use a token for a question about how to turn on object pooling within Windows. The starting point is that how to turn on object pooling has nothing specifically to do with Manifold. It is an exclusively Windows thing that has to do with any objects one might want to have in play, and not just Manifold objects. Manifold IMS will work perfectly whether or not you turn on object pooling in Windows, just like it will work perfectly whether or not your disk system uses a RAID configuration. Both object pooling and RAID are matters of the environment, not of Manifold. Therefore, on the face of it asking a question of Manifold technical support on how to operate this particular Windows facility does not fit into the technical support services provided by Manifold. However, because developer incidents are much more broadly interpreted there's actually a pretty good chance that even though this is not a Manifold facility a developer incident would get back a useful reply. It's not guaranteed, and you might just get back an answer stating that this is a Windows matter not a Manifold matter, but in my experience there's a good chance, certainly better than 50-50, you'd get back a useful reply. If that happens you are just getting lucky that Manifold engineers responding to developer incidents tend to know a lot about Microsoft stuff in addition to Manifold. The key question is whether that "useful reply" would be as useful as asking that same question of a tech support organization that specializes in support for Windows as opposed to supporting Manifold. It is very flattering that people routinely seek support from Manifold's organization even when they know up front it is entirely a Microsoft matter, but the reality is that it is unlikely an organization with a Manifold focus can do as good a job in Microsoft matters as an organization with a Microsoft focus. I'd therefore offer the following algorithm for making a decision: First, consider what resources you have for Microsoft support. If you have free resources, like some unused MSDN support spiff, use that. If you don't have free resources for Microsoft support, what does it cost you to buy Microsoft support from whatever channel you favor? If it is significantly more to get Microsoft support than the $99 you'd spend with Manifold, then perhaps it makes sense to try $99 with Manifold. If you do choose to venture $99 to try your luck with Manifold on a matter you know up front is not explicitly covered, go into that transaction taking responsibility for that. It could be tech support gives you a brilliant and helpful answer. It could be that they give you a quasi-helpful answer that leaves you thinking "I see now why they focus on Manifold." Or, it could be they reply that's not Manifold and you should consult your Microsoft resources. With developer incidents, the usual practise in cases where they haven't had to spend time to extract information to figure out what the customer is asking, if it is right off the top evident this has nothing to do with Manifold and they cannot help they'll tell you that and won't charge the token. However, in that case you have a token you paid for that cannot be refunded. You can use that in some future case but if you don't ever need to use it that's $99 sitting on the shelf. There are good reasons why despite the enormous economy of scale enjoyed by Microsoft that developer support for Microsoft can cost a lot. If it costs you $500 to get a question like this answered through a Microsoft channel then I'd venture the $99 with Manifold. If it cost me only $150 with Microsoft then I'd use them. Or, I'd start hanging out in Microsoft development forums and ask there. :-) Hope all the above helps. Support incidents are useful but they are not free and they can't solve all the world's problems so it's important to know the ins and outs of using them to get the most out of your hard-earned money.
|