Tech Support Horror Stories (Crescent)

Tech Support Horror Stories (Crescent)

Post by No parking EXCEPT FOR B » Sun, 30 Jun 1996 04:00:00

Well, I used to just love Crescent.  When they were acquired by Progress,
I didn't think it hurt anything.  I still doubt that has to do with what
I'm finding now.  I found it no big deal when the PowerPakPro 1.0 docs
all had a wrong number for Tech Support - at least the techs at that
other part of Progress Corp were able to get me the right number.
But even then, a year ago, no one could tell me how to determine
which property of each control from QuickPak/PowerPak was its "default"
property.  I had a backlog of legacy code that needed updating,
and it used "default" properties all over the place.  So, much more
work for me, I had to test & figure them out for myself.  Something
that _should_have_been_ a simple entry in the manual and helpfile.

But I let that go, and happened to not use their VBXs for a few months.
I still believed that I had a suite of good quality tools to rely on.
And now...

All I wanted to do was use the CSTEXT.VBX  from QuickPak/PowerPak
(I've paid for both packages, including upgrading to the new OCXs).

My client brought me an application with Masked Edit (MSMASKED.VBX)
controls all over it, and they just want some slightly different

  For the display-only fields, they want the appearance
  of a label, and for the user to be unable to change
  the value.  Setting a MaskEdBox enabled=false makes
  the text gray, and that's unacceptable.  And they want
  right-alignment, especially of dollar values.

  For the read-write fields, they want right-alignment,
  at least when the control does not have focus.

Looks like a very easy task for two controls in CSTEXT.VBX, the
CSDouble and the CSCurrency.  They have a "DisplayOnly" property
distinct from the "Enabled" property, and a "Justification" property
(though why the latter isn't named "Alignment" and why it stores
[0, 1, or 2] in the .FRX file are complete mysteries to me)

So I began the conversion.

A few days later, everything began to unravel.

Unfortunately, if CSCurrency is bound to a value of type double, such
as a query calculation, and the number is very small, for example
"$0.0000001234" (1.234E-7), then CSCurrency incorrectly displays "$1.234"
Clearly a bug.

Crescent tech support, in the person of Robin Cohoon, admitted:
    "There is no way to get the double control to
     diplay a $ symbol and the currency control will
     not read scientific numbers and do the conversion."

In further email, she tried to be helpful, but didn't seem to be able
to understand that I MUST bind to a database and can't afford ten lines
of code for every one of the dozens (if not hundreds) of controls in
my project.  Any suggestion that includes "put this code in a click event:"
isn't much good in the real world.

So, CSCurrency is worthless.  It can't be bound to a query result
and be expected to show numbers of even the correct order of magnitude
if the result is nonzero but so small that zero should be displayed.

I could write some code, for EVERY control I instantiate,
but should I have to?

Next, my users begin to enter some test data, and all the reports
start turning up blank columns.

It seems that CSDouble writes a null to the database when the user
enters zero, and nothing I have tried will make it write the VALUE of
zero to any database field.

Unless that can be fixed, CSDouble is, also, worthless.

Did these guys TEST anything?
Did any users every really BUILD anything with these?

Crescent have not responded to my further inquiries.  Well, OK, so
I haven't given them a lot of time, but my three month project is now
weeks late, and (after Crystal Reports) Crescent is the second leading cause.

I'll leave the horror stories about their OCX package, such as unexplained
shipping delays measured in MONTHS, for some other post.

Can anyone (even Crescent) suggest some bound controls that can do
these things?  I have a firm requirement to minimize code, so any
solution that requires more than a couple of lines per control,
or can't be executed in the change event, just isn't acceptable.
I'd sooner give up the right alignment, and go back to using
pairs of MaskEdBox & Label controls for read-only.  I hate MSMASKED.VBX,
it's so weak, but at least it reports actual values and can write
a zero to the database.

Maybe it was "PDQ" rather than Crescent, all along, that I liked.
Whatever that character string means from them...
PDQBasic, and PDQComm did everything I ever asked from them, and
did it well.  I bought QuickPak, and later the PowerPaks, on the
strength of that history.  I still hope Progress/Crescent can
prove to me they deserve something better than to be slammed.

     Bob O`Bob


1. Horror Story - RD Support!

Here's a horror story about Raining Data's support that just happened...

Last week I travelled to Pennsylvania to install a new system. We spent
Thursday and Friday converting the new client's data from DOS to Pick.
Installed our application on their brand new Dell server running RH6.2
and D3Linux 7.2.0. I installed all the software and OS using the same
techniques I have been using for 3 years on dozens of Linux servers.
The tape back up did not work.
We called RD for some advice late Friday afternoon. I told them that this
was the east coast, it was now almost 4:30pm and we would wait for a call
until 6pm. No call ever came. We finished training on Saturday and Sunday
and I headed back to Florida.
Monday around 11am I get a call from the hardware guy at my new client.
Seems that he has been on the phone with someone at RD who told him the
reason the tape drive didn't work was that D3 was installed incorrectly.
He said that there has to be a "d3" partition. I have been using "d8" as
the partition type for 3 years. He had the hardware guy reinstall D3Linux
which wiped out 4 days of work with no backup to recover from.
Since the tape drive was still not working, even after this bonehead
move, I had to upload the entire application and reconvert the client's
data, at my expense, over a 56K dialup connection to the client.
There are 2 morals to this story. First, don't ever let the client do
anything to their system that RD tells them to do unless they check with
you first. And second, someone should tell the tech support staff at RD
that you call the VAR before you wipe out someone's system, especially if
you don't know what the hell you are doing in the first place.

By the way, it turns out that the tape drive was defective.
Ricky Ginsburg can be reached at:


2. VB5 - ok

3. OT: Tech Support Story

4. Query to get Identity Field

5. Upgrade horror stories/victories

6. Which TCP port will be used on an MSDE2000 install?

7. Are there any D3 B-Tree Horror Stories?

8. Date Time Picker - Null Date

9. SQL 6.5 SP5a Horror Stories...?

10. OLAP Horror Stories

11. Resync , Identity, Join Horror Story

12. System 10: Is Horror Story True?

13. horror stories