G'day Mike,

I'd reply to you personally to correct some of the errors in your
logic and untruths in your communication but that would not set an
example of standing up to and handling a black propaganda campaign.
Which, I might add, is a very UNPROFESSIONAL and UNSEEMLY (if I
may borrow a capitalisation technique I recently learned from
someone) technique for a firm to adopt towards one of its' own clients.

SANE people attack their enemies (in commercial terms their competition).
INSANE people attack their allies (customers).

I do not think that taking exception to a legitimate post by a
CURRENT and LOYAL user of R:BASE and attempting to discredit
and marginalise his communication to be the best business
practice and hardly PROFESSIONAL conduct to become offensive and
attempt to put the blame onto the developer's "poor logic" when
he takes the time to report a bug.

I spent several hours documenting the previous bug only to be
told that it was too complex an example I sent and that I
should reproduce it in ConComp.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

At 16:32 26/11/02 -0500, you wrote:
At 07:36 AM 11/27/2002 +1100, Tom Grimshaw wrote:
I don't know if RBTI are going to have time to get around to this
prior to "closing the books" on 6.5++ so here is a workaround for
anyone who applies the latest patch and encounters the edits not
being saved bug.

Just go back to version 1.851 where the problem does not exist.
Dear Mr. Grimshaw;

With all due respect, I must say that encouraging the R:BASE community to
revert to an antiquated build of R:BASE 6.5++ is quite counterproductive and
not a very wise move.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is illogical.   To the best of my knowledge one could hardly
describe the most recently pre beta and still only current shipping
version as "antiquated".   But then again, it does match some of the
more critical comments I have heard about the current version of
R:BASE, still, not a term I would have expected to hear from RBTI.

If you fix several minor things and break a mission critical one in
the process which is more counter productive?   Attempting to gloss
over it and discredit the developer bringing it to your attention
and blaming his "poor logic" or making one's contemporaries aware
of a potentially disastrous distribution of malfunctioning or poorly
conceived and modified software?

It appears I care more for my fellow developers and their clients than
RBTI do.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So many things have been fixed and added to the latest
build that down-grading to the 1.851 build is like trading in a 2002 BMW for a
1990 Yugo (no offense intended to all the Yugo lovers out there!)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Another illogical, incorrect and offensive extrapolation that does
not solve the problem but attempts to discredit the messenger.

Fixing a few minor problems and creating a major one is like cutting
out a few warts and removing the patient's head.

I personally don't care how many warts you cut off if you remove the
patient's head in the process!   The patient is still dead.   The warts
were never going to take him out but the headectomy was never going to
be a pro-survival move.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In a message dated 11/25/2002, the staff at RDCC requested that you send a
sample of the anomaly so that we could verify whether or not it was an issue
that needed to be addressed. As of this moment, we have not received
anything on your behalf relating to this issue.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Well this is the reply I received when I clicked on the reply to address in the RDCC email:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Delivered-To: [EMAIL PROTECTED]
Date: 26 Nov 2002 20:47:11 -0000
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: failure notice

Hi. This is the qmail-send program at securenameserver.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<[EMAIL PROTECTED]>:
166.102.165.50 does not like recipient.
Remote host said: 550 relaying mail to mail.rbasetechnologies.com is not allowed
Giving up on 166.102.165.50.
--- Below this line is a copy of the message.
Return-Path: <[EMAIL PROTECTED]>
Received: (qmail 18181 invoked from network); 26 Nov 2002 20:47:10 -0000
Received: from cpe-203-51-36-15.nsw.bigpond.net.au (HELO hplaptop.just4usoftware.com.au) (203.51.36.15)
by rp.nsw.gov.au with SMTP; 26 Nov 2002 20:47:10 -0000
Message-Id: <[EMAIL PROTECTED]>
X-Sender: [EMAIL PROTECTED]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 27 Nov 2002 07:52:23 +1100
To: [EMAIL PROTECTED]
From: Tom Grimshaw <[EMAIL PROTECTED]>
Subject: Re: Edits Being Overwritten
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

G'day,

I have just confirmed that what I am experiencing IS a new bug
introduced in the latest patch and not the result of "poor logic"
as you so rudely suggested.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To date, the R:BASE community, both private and public, has been testing the
latest 1.861 build with great enthusiasm, and has not reported any problems in
this area of the forms package.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
But Mike, that is just an untruth.   I have reported it.   More than once.
Or is this just an attempt to make nothing of me by further indicating
that I do not count?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Another important issue to consider is that as the versions and builds progress,
we are doing our best to weed out all the inconsistencies and improper behavior
of prior versions. In using the older versions, it is very common for a developer to
use the logic of two "wrongs" to make a "right." Now, we have to be reasonable
when it comes to using the new logic of two "rights" to make a "right."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I hardly think it accurate, logical or productive to marginalise my
methodology as "wrong".   What is "wrong" with displaying a list of
records in view only mode, clicking a button to display an edit screen
for one record, making the edits then returning to the viewing form?

I fail to see the "wrongness" in that methodology and nobody has yet
come forward to suggest how you would scroll down a list of 200
records, making edits and having them save without priorly closing
then reopening the list form which would necessitate scrolling down
from the first of the 200 records after every edit.   Be easier if we
had a scroll bar, but of course we don't.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On behalf of the entire R:BASE community and Development Staff, I think that
it is a grave injustice to make suggestions like the aforementioned.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
My opinion is that it is more unjust to shoot the messenger than it
is to fix the malfunction.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

At this point, the R:BASE Developers are well aware of how we work and handle things
like this,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That is true.   I have observed first hand the remarkable inconsistency
of handlings from RBTI and I'm aware from private communications that
I'm not alone in observing them.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

and also that there is a proper procedure that must be followed if any
action is to be expected. To jump to such a premature conclusion is not the
proper or productive way.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Your claim that is was not "proper" or "productive" is incorrect.

If you are winding up the development on the current version it is
hardly "premature".   And if, as Razzak suggested, a great many people
are using the beta releases in a production environment, how is it
"premature" to warn them of, what in my case would have been, most
disastrous indeed to have distributed to my clients.   As it was it
cost me hours.

Just as an aside, one of my developers suggested as much that I was a
couple of shovels short of a barrowload by using beta software on a
production database.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I would hope that you would direct your efforts towards narrowing down the
issue, and sending a reliable and replicable example to the dedicated folks at
RDCC so that if there actually is a problem, we can get to work on it.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I guess whether or not you think that there is a problem depends
very much on your viewpoint - whether or not you use the methodology
that I do. And when you find out about the changed functionality.
Before or after you ship it to your clients. Very fortunately for
me it was before.

The last time I did as was requested and was informed that my example
was "too complex" and was to be submitted in ConComp.

For mine, I am happy enough with the prior version without the
malfunction. I don't mind the warts if it means I keep my head.

From the lack of corroborative postings it appears that nobody else
seems to require the functionality that I use so if you are happier
marginalising customers than solving problems then that is your right.
Just as you have every right to choose whose bugs you fix and whose
you don't.

I wish you all the luck in the world.
Without treating your customers with more respect than has been
shown in my direction you're sure as heck going to need it.

But then again, that is your right.

Warmest regards,


Tom Grimshaw
coy: Just For You Software
tel: 612 9552 3311
fax: 612 9566 2164
mobile: 0414 675 903

post: PO Box 470 Glebe NSW 2037 Australia
street: 3/66 Wentworth Park Rd Glebe NSW 2037

email: [EMAIL PROTECTED]
web: www.just4usoftware.com.au

"... the control of impulse -- is the first principle of civilization."-- Will Durant,
Pulitzer Prize winning philosopher, writer and historian

the most needed product in the world can be found at
www.thewaytohappiness.org

This email and any files transmitted with it are confidential to the intended recipient and may be privileged. If you have received this email inadvertently or you are not the intended recipient, you may not disseminate, distribute, copy or in any way rely on it. Further, you should notify the sender immediately and delete the email from your computer. Whilst we have taken precautions to alert us to the presence of computer viruses, we cannot guarantee that this email and any files transmitted with it are free from such viruses.

================================================
TO SEE MESSAGE POSTING GUIDELINES:
Send a plain text email to [EMAIL PROTECTED]
In the message body, put just two words: INTRO rbase-l
================================================
TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED]
In the message body, put just two words: UNSUBSCRIBE rbase-l
================================================
TO SEARCH ARCHIVES:
http://www.mail-archive.com/rbase-l%40sonetmail.com/

Reply via email to