It looks like this was already discussed here quite recently, but I couldn't
find out the thread, and don't remember what the verdict was brought in.

D3 Win 7.2.1, a data portion of the file in the FSI-based account with a
trigger set up in the dict. Any attempts to CALL, EXECUTE, CHAIN,
OCONV(ITEM,'u10'), etc. won't work. The subroutine exits at the appropriate
statement without a trace. Though I'm wrong, 'u10' approach just clears out
the jobs file.

I wonder if anybody knows a workaround/resolution. Or do I need to simply
give up once again?

TIA
Nick

Nikolai Lukin ha scritto:
Is the subroutine Flash compiled?
Is it referred by a full path?

Stefano

Stefano,

Thanks for your reply!

Answers to your questions:

1. Yes it's Flash conpiled, in particular with (fbo options.
2. Yes, it's referred by the full path.

Moreover, the same routine works well if it's called in a regular way.

I also found that neither U50BB, U10 nor @USER, nor @PIB functions
will work from a trigger while they work well in regular manner.

In its turn @ACCOUNT returns proper value in both cases. But the
critical one is U10, which is in charge of the phantom job launch.

Any ideas?

TIA
Nick


On 6 æÅ×., 12:42, stefano <stef... (AT) friuldata (DOT) it> wrote:

I don't have time to research issues Nick but I can tell you that what
you're doing relies on VME services which could be problematic in D3NT
just based on the way triggers are executed in a different process.

For years I completely avoided triggers. A couple months ago I
decided to give them another shot so that I could change my position
or at least have current facts to support my existing position. My
efforts are documented in the RD forum and I never was able to get
triggers to work reliably or sometimes at all on specific file types.

Based on my own trials, and seeing what Dave Sigafoos has been going
through, I'm going to continue to avoid triggers in D3. The docs are
incomplete and inaccurate, there are too many platform
incompatibilities, it's too prone to release-specific issues, and
there are too many non-intuitive nuances which make the difference
between success and failure. In my mind it's too fragile and just not
worth the aggravation, especially for a solution which a vendor will
deploy to an end-user site. I'm sure others disagree.

T

Hi Tony

Exactly why I don't use triggers.
Do great minds think alike!
Peter McMurray

PS I am delighted to see that you did not split the infinitve. "I never was
able to get"

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

On Feb 6, 5:02 pm, Tony Gravagno
<g6q3x9lu53... (AT) sneakemail (DOT) com.invalid> wrote:
Tony,

I don't think that I would give up on triggers. Triggers are the only
way to trap ALL read/write processing.

My problem with triggers is coming back to D3 after working in a lot
of other environments and coming with certain expectations. I
expected that a trigger, being a low level 'event', would know all
about its environment and all things going on. That is simply not the
case.

Like some of the newer features in D3 it *appears* (this may be cruel
and hopefully not true) that triggers were simply bolted on the sides
like a wing on the back of a kids car <G>. You've seen them, those '1
size fits all' wings that look like they came from an erector set <G>.

We tend to design our SW to be shared between accounts/applications.
This is a little more problematic with triggers.

What would have been nice is if the documentation at least was
complete AND mentioned limitations. Of course they may just not know
the limitations as they probably don't use a feature like this other
than to test that it works and have a 'check box' on the packaging.

Thankfully there are groups like this one with people willing read and
understand the question then willing to help (other than 'read the
manual').

So, i guess in my long winded way i am simply saying D3 Triggers are
useful but it appear in a very limited scope.

DTsig

Tony,

Thanks for useful comment. To my experience triggers are useful and stable
enough in D3 Linux when used in limited scope. My idea was in extending some
application functionalities by means of triggers, and it was in D3 Windows.
Now I realize that it won't be accomplished according to your and others'
reasonable explanations.

Cheers,
Nick

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ ×
ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ: news:cg7is2tb64h8d9dshb1ur2jn7cv2nrsa15 (AT) 4ax (DOT) com...

General response, not just to Nick.

My usual mantra is that product problems should be presented to the
vendor. Business and technical needs like this that are presented in
a public forum have a high chance of being unsatisfied. That leads to
workarounds, migration from the specific MV DBMS, or from MV entirely.

I don't have an application where triggers would be useful, you do.
I don't have clients asking me to make triggers work, you might.
If one of my clients asked me to fight the fight I'd be on the phone
today with RD, with a list of issues for software and docs, pressing
for remedies in the next point-release. If I had a client who needed
this functionality on a regular basis I'd beat the hell out of it in
each beta release to ensure that we collectively didn't get a release
that was unsatisfactory.

Here is yet another feature that some people will now stop using, and
because no one is testing it in the field or reporting issues, more
bugs will creep in over time, and more people will decide to stop
using it. It's a downward spiral that could easily go the other way
for this vendor or others.

I guess I should hop into my business shoes and offer beta testing for
specific features as a service. If you don't want to test features
like triggers, but you'd really like them to work, I ask you to
consider commissioning Nebula R&D to spend time with triggers and on
the phone with RD in the next beta. Of course this applies to any
feature that matters to you. The question to ask yourself is, if
feature X breaks and you can't use it anymore, how much time and money
will it cost you to change your code to use a workaround?

"But I'm already paying RD to do betas and QA" you say? Well, yes and
no. RD got rid of almost all of their QA people, almost all of their
doc people, and there's hardly anyone left who has time and knowledge
to test the software for the things that are important to you. Why do
things like that happen? I'd say it's in part due to people more
willing to change platforms than to send an email to their vendor to
discuss issues that we see in these forums every day. So at this
point, if you want something done right you have to do it yourself, or
get someone else to do it for you. On the plus side at RD I believe
RD has an excellent team heading up Engineering and Support now, so if
you haven't communicated with the tech people recently then I suggest
you give them a shot now.


Regards,
TG@ your.personal.QA.companyNebula-RnD.com