Re: Trigger on a Qfile ... WHAT??
- From: dtsig <dtsig@xxxxxxxxxxx>
- Date: Wed, 28 May 2008 15:33:25 -0700 (PDT)
On May 28, 1:57 pm, Tony Gravagno
<address.is.in.po...@xxxxxxxxxxxxxxxxxxxxxx> wrote:
dtsig wrote:
On May 28, 10:54 am, Kevin Powick <kpow...@xxxxxxxxx> wrote:
On May 28, 1:19 pm, dtsig <dt...@xxxxxxxxxxx> wrote:
Normally I would put a trigger on the file forcing specific set of
rules ... BUT if you have a qpointer to the os directory, is there any
way to attach a trigger to that?
Is there another way???
Yes. Explain the naming conventions to your programmers and inform
them they will be shot if they deviate from this standard. Also
indicate that their family will be charged for the bullet.
--
Kevin Powick
Well .. as long as i have a good fool proof system <G>
While it's not too popular here I'm also fond of breaking fingers of
developers and end-users - before or after the bullet, I don't care.
Dave, you're going down a path that I went down when we had a similar
discussion on this sometime last year. I did some research in this
area and concluded that triggers in D3 were not supported well enough
across the entire platform, and this only reaffirmed my conviction
simply to never use them. There was some dissent and RD came back
with a "tell us what doesn't work". But:
1) When I point out what doesn't work it doesn't change.
2) I'm not getting paid to do their QA.
3) It's as easy for them as anyone here to attempt to put triggers in
various places and see where they do and don't work.
My biggest gripe with this is that no tech notes have been issued to
tell developers exactly where triggers do and do not work. It's left
to the individual in the field to do the legwork, following a line of
colleagues who have done the same. And since things tend to break
from one release to the next there is no standardized test that can be
run (which should come from RD/TL QA if they still had a QA
department) that allows developers to know when the next release will
break functionality which worked previously. As usual the process is:
- Code in release 1.
- Install release 2.
- Find the feature is broken.
- Code a work around.
- Wait for a functional release.
Unfortunately at that "code a work around" point, many developers get
frustrated enough to port to a new platform rather than waiting for a
functional release. For those who do get the next release, they've
already coded a work around, so they really don't care about whether a
feature was fixed or not. After doing this several times their
software is now generic enough to port just about anywhere. Since
these people migrate rather than using the features that RD/TL
breaks/fixes, the issues are never reported again. New people trying
the software find many features broken, decide D3 is a disfunctional
platform and they move on.
This scenario plays out every day and RD/TL wonder why they need to
come out with new products and new corporate directions in order to
turn a profit. Duh. Assure quality. Document functionality.
Encourage people to use what works and report what doesn't. That will
get people to buy and keep the software.
Back in broken record mode, sorry. The problem is that people
(especially at RD/TL) read stuff like this and go "Tony is on a rant
again", completely ignoring what the rant is about - and completely
forgetting that before these things were rants they were polite notes
encouraging productive change. Since that change hasn't happened our
market has grown smaller and all I can do about it now is rant.
Whatevah....
T
Let's face it .. they don't have any ownership in D3 other than to
sell something. This is similar to what happened with revelation
software then JA (The Dark Overlord) took it over to the point of
extinction. Hopefully someone will get D3 away from the investors and
do what needs to be done.
Thanks
.
- References:
- Trigger on a Qfile ... WHAT??
- From: dtsig
- Re: Trigger on a Qfile ... WHAT??
- From: Kevin Powick
- Re: Trigger on a Qfile ... WHAT??
- From: dtsig
- Re: Trigger on a Qfile ... WHAT??
- From: Tony Gravagno
- Trigger on a Qfile ... WHAT??
- Prev by Date: Re: Trigger on a Qfile ... WHAT??
- Next by Date: Re: Quick primer on Unidata-to-SQL Server Connectivity?
- Previous by thread: Re: Trigger on a Qfile ... WHAT??
- Next by thread: Re: Trigger on a Qfile ... WHAT??
- Index(es):
Relevant Pages
|