Hi

I'm new to D3/NT.

I'm doing a readu then a write to an fsi file in another account. In
case it makes any difference I'm opening the file with: OPEN
'www,w3Html,' TO filevar ELSE DEBUG. The lock continues to show on
list-locks afterwards and the item isn't updated although the program
moves on (without taking the on error clause) as though everything's
hunky dory. As the file in question will be familiar to many
FlashCONNECT users (who also use D3/NT) I'm wondering if anyone else
made whatever silly mistake I'm making.

Mike.

Mike:

Which version of D3NT. This product has a nasty habit of producing very
unexpected results, like crashing the VME, under certain circumstances.

With each upgrade of D3NT the product improves. Another problem could be
which version of Windows are you using. I have a client that uses D3NT v7.3
on Windows NT v4.0 w/SP6. I can crash the VME any time I want by simply
using OSFI. So, like the doctor says, "I don't do that!". Usually, a
weekly reboot of D3 and Windows each week keeps the product running ok.

Last week, however, I found where I would edit a record directly, make a
change, then file the record. The record wasn't changed. Tried about 5
different ways to change and file the record. Rebooted D3 twice. Still had
the problem. Finally, I rebooted Windows. Cleared right up after that.

Hope this helps.

Bill


"Mike Preece" <michael (AT) preece (DOT) net> wrote

I don't believe this is related to FlashCONNECT Mike. I believe I've
written code like yours without a problem. I will encourage you,
howerver, to keep all app-specific items out of www, as with all
vendor-provided accounts, so that you have less pain at upgrade time.

According to D3Ref:
---
The "writex", "matwritex" and "matwritexu" statements all have
the property of waiting until the actual disk update takes place
before continuing execution of the program. They are used for
"critical" write-through, such as error-logging. An optional
"on.error.clause" may be specified. This consists of the words "on
error" followed by a statement list. The clause is taken if the update
fails because the data source is unavailable (as can be the case if
the file is remote), or if a callx correlative applied to the file
fails because of an "inputerr" statement.
---

Personally I don't think WriteX or "on error" will totally fix what
ails you because I doubt they are ever tested and therefore there is a
good chance they will break between releases. We need a commitment to
WriteX and we need an enhancement for DeleteX and ClearFileX. We also
need a consistent ELSE clause for all statements which can fail on
remote disk updates, rather than some having ELSE, some having ON
ERROR, and some having ONERR. I've ragged about this many times and
filed at least one action item but no one seems to think this is
important enough to force a change - but anyone who ventures into this
area seems to find the problems. *sigh*


Tony Gravagno, Nebula R&D
TG (AT) elseonerrorwhateverNebula-RnD (DOT) com

Technical Editor, "C#Builder Kick Start"
Now Available in book stores and Amazon.com
http://www.amazon.com/exec/obidos/AS...2325896/cstati

michael (AT) preece (DOT) net (Mike Preece) wrote: