Another look at Informix Support

I've read the debate about Informix Support with a lot of interest; the below message was one of the clearest expressions of what seem to be problems with Informix's Technical Support personnel in terms of how their "help" is perceived by customers. In light of the *many* negative comments about this aspect of Informix, I would suggest to that company that it respond to this negativism not by rejoinders but by recognizing that, if the customers feel that they've not been helped, then there *is* a problem, even if it is only one of perception. In attempting to resolve these issues, I would further suggest that Informix undertake the taping of Tech Support conversations, just as other companies tape conversations between public representatives and the public, and that these conversations be spot-checked by persons *not* in Technical Support to check for: 1) Agreement between the written/electronic record of the conversation and the taped version. 2) Customer satisfaction with Technical Support (by directly contacting the customer). This sort of inquiry would soon give Informix a measure of how effective its organization was being in both: 1) Actually helping customers who call Tech Support. 2) Leaving those customers with a positive image of both Tech Support, specifically, and Informix, generally. If this process were taken up with an open mind, then whatever is occurring to create the sort of frustration, disgust, etc., recently mentioned "in this space" should be found out, and steps could be taken to constantly improve those aspects of Informix's operations. I hope that Informix can see that some such investigation of these complaints is warranted, since unhappy customers increase a company's *bad* reputation faster than happy customers increase the a company's *good* reputation. (I read or saw something a few months ago which stated that, if someone has a bad experience with a business, that person will tell about 7 other people, while, if the experience is good, that person will tell only 4 other people, on average.) Steven J. Richardson Merit Network, Inc. University of Michigan, Ann Arbor, MI ---(Forwarded from: kuhn@rhlab.UUCP, Dated: Thu, 23 Apr 92 13:32:34 EDT)--- Received: from rmy.rmy.emory.edu by um.cc.umich.edu via Internet with TCP; Fri, 24 Apr 92 09:31:21 EDT Received: from csslc.rmy.emory.edu by rmy.rmy.emory.edu (5.65/Emory_rmy.3.3.5) via SMTP id AA14203 ; Fri, 24 Apr 92 09:31:23 -0400 Return-Path: informix-list-owner@rmy.emory.edu From: kuhn@rhlab.UUCP (mjk Michael Kuhn) Message-Id: <464@rhlab.UUCP> Subject: RE: Informix Support, Where Are You? Date: 23 Apr 92 17:32:35 GMT Reply-To: kuhn@rhlab.UUCP (mjk Michael Kuhn) Organization: Baltimore Rh Laboratory, Inc., Maryland Sender: informix-list-owner@rmy.emory.edu To: informix-list@rmy.emory.edu X-Informix-List-Id: <news.1087> I have a few comments about Informix Tech Support. I have always gotten an efficient, courteous Tech Support person. If you were to go back and look at the support logs from my phone calls you would probably find that the customer was helped every time. From Tech Support point of view this is probably true, from my point of view this is not always the case. The PROBLEMS 1. Three releases in a row I had trouble with DBLOAD. Scripts that I had broke. Problems with upper and lower case of keywords and problems with too many delimited variables (if 11 or 12 is too many). 2. CONSTRUCT bug core dumps when query on last field. 3. Long Queries as a result of the new optimizer in 4.0 These are just a few of my calls. In all of these problems the records would show that I was helped by Tech Support. The HELP Number 1. There is another bug in DBLOAD we don't know when it will be fixed, you will have to talk to Sales about a new release. Number 2. It's a bug we don't know when it will be fixed, but it is high on the priority list, customer was helped because Tech Support said to put a dummy field at the end. I did not use release 4.0 for 9 MONTHS because of this bug. I finally broke down and dummied up some screens and construct statements. Number 3. Queries are still causing me trouble. The optimizer seems to insist on doing long joins before applying some simple filters to an indexed table. Example: select s.sno, s.batchno, r.trayid from sample s, result r where s.sno = r.sno and s.batchno = 15 batchno is indexed, sno is indexed in both tables. Query Optimizer joins all of the rows from sample and result by sno and runs them all through the filter to find batchno 15. This did not happen in the 2.0 releases. It would have picked the 30 plus samples from sample for batchno 15 and then joined them with the 240 plus rows in result. result has 8 times the rows that sample does. Should it not use the indexed filter on the smaller table first? The FIX is to split this into two queries. This is the help that Tech Support will document. Believe me the customer was not helped. Tech Support does not cause me any grief, they are just working people like me. I personally would find it difficult giving advice to clients knowing that some of the problems that I was hearing and dealing will not be resolved for many clients for MONTHS. Attention Informix: Do not rely on notes from Tech Support to determine whether the company is addressing the needs and complaints of its customers. -- Michael J. Kuhn Consultant phone:410-254-7060 Email: rhlab!kuhn@uunet.uu.net or uunet!rhlab!kuhn c/o Baltimore Rh Typing Laboratory, Inc. phone:410-225-9595