M2M Tech Support Gaffes

As a follow up to my last post in which I said that you need to be careful following the free advice given by another customer; you should also be wary of what M2M Tech Support tells you. They can and do make mistakes. I can’t tell you how many times they’ve given me directions which were for the wrong version of M2M as well as a SQL script which was incorrect and would have caused huge problems with my database.

For example, when I first started working with a Visual FoxPro version of M2M (3.1 I believe), I had problems with one of my invoicing tables. There are as many as 3 files with each VFP table. The first file contains the data, the second contains any indexes, and the third contains memo fields. The Tech told me to delete the file which contains the index structure so that it could be rebuilt, but gave me the extension of the data file. I asked her to verify the file and extension she wanted me to delete and then did so. Of course, this was a mistake. Shortly thereafter I found out that the company we paid to do network maintenance and check our back ups was not doing so, and I had to restore an invoicing table from two weeks back. I then hired a VFP programmer to update the table using information from related tables. This was stupid on my part, but as I said I was a complete beginner and had no idea.

Later, when I first started with Crystal, I was instructed to use the SA account, the same account most M2M installations are configured to use. This is a bad idea for several reasons, but as I said, I was a beginner at the time. However, I did not know the SA password, so Tech Support showed me how to change it…. during the work day… with everyone in M2M. I specifically asked, “Will this cause problems for my users in M2M?” The tech assured me that no, it wouldn’t. Well, the results were predictable, exactly 1 minute after doing it, I had 3 calls in rapid succession from users getting all sorts of SQL Connection Errors. Nice.

Recently, I received a script I was told to run by a Senior Tech Support Rep and it began with:

--Change the database name before executing this query
use mercury
--Find inonhd records without matching inmast records

Obviously I am not going to change the name of our production database with users in the system, nor does it make any sense to change the name at all. Most of their scripts will tell you to “use DataXX” and this is more clear.

After I questioned the support tech about that, she verified that I should just run the scripts against M2MData01. I didn’t understand the reason for one of the update statements, so I checked it out as a select statement first and it returned almost 3000 records. If correct, this would indicate a serious problem in my database. I immediately stopped and called the Support Tech and she apologized that the script was in error and should not be run against my database. If I had run the update script, it would not have been an easy fix.

As a general rule, make a copy of your M2MData folders before changing anything. Do not assume your backup will suffice. It’s much faster to “restore” from a duplicate copy right on the drive than messing around with tapes. If I had simply done this I would not have found myself in a terrible spot with my first example.

This post isn’t meant to jab at M2M. These problems are not always their fault. Unless they are looking at your screen they are relying on you for the answers to their questions. Having helped people out this way, I have a new appreciation for just how difficult it is to guide a user through a process that you cannot watch.

Anyway, the point is that M2M does not administer itself, and if you are going to administer it you need to learn it. Don’t blindly follow directions as even the best Support Technicians make mistakes.

Have any of you encountered similar issues?

1 comment to M2M Tech Support Gaffes

  • Stephen

    Actually, I’m kind of surprised that Support doesn’t do more remote access than they currently do. Having been in support for the first 10 years of my career, I’ve learned that there’s a big difference between what the screen actually says versus what the customer tells you on the phone.

    At least by email, I have the opportunity to send in screen caps and document a problem with higher fidelity than over the phone.

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>