Re: Timing problem on file deletes

On Tue, 7 Apr 2009 09:36:14 -0700 (PDT), dlzc <dlzc1@xxxxxxx> wrote:

Dear Scott Coffey:

Stephen Quinn's advice is rock solid. Be sure you appraise it.

On Apr 7, 6:49 am, Scott Coffey <n...@xxxxxxxxxxxxxxxxxxx> wrote:
On Mon, 6 Apr 2009 15:58:20 -0700 (PDT),dlzc<dl...@xxxxxxx> wrote:
Dear Scott Coffey:

On Apr 6, 3:21 pm, Scott Coffey <n...@xxxxxxxxxxxxxxxxxxx> wrote:
I figure it's some sort of Windows file
caching weirdness but how do I go about
truly deleting a file?

COMMIT works on this sort of operation too.
Try it after each erase operation.

Funny you should mention that...

The problem I'm trying to solve is this:

All of a sudden, the user reports that sold
items are missing from a printed receipt.

What changed from "before" through "all of a sudden" to "now"?
WinDoze updates, and what else? Remember Micro$haft propagates bugs
in with their fixes, so they can move customers to new OpSys
purchases.

"All of a sudden" came on the heels of some program modifications but
I can't attribute this behavior to any of the mods. Doesn't mean it
couldn't happen though...

I considered that it might be a Windows update that caused this
behavior, but I'm not sure I buy into the conspiracy theory. :)

 The application uses standard order header
/ detail files.  The detail file is called
LINES.  The program uses the following op
code in the receipt print program:

select LIN
set filter to ORDNBR = ORD->ORDNBR
go top

Better to index LIN on ORDNBR, seek ORD->ORDNBR, and do while ORDNBR =
ORD->ORDNBR

I agree. Be advised that I inherited this bag of snakes and haven't
attempted to rewrite the thing. Programs I have written do as you
describe and don't use the "set filter" technique.


The items are in the LINES file but not
printing.  This problem recently occurred
and happens infrequently.

Which means it is usually safe assumptions in your code... like the
OpSys is well behaved.

 It's only been reported a few times.
 Exiting and re-entering the program appears
to "fix" it. Since the data is in the file,
I suspected an index problem and that's
where the "witchcraft" of deleting the index
file prior to creation came in.

Understood. You cannot out-witch the warlocks at M$.

 While doing additional research I came across
the "commit" op code.  I had seen it before
but it was always in the context of a
network environment which doesn't apply in my
case.

Won't matter. Actually works on a local drive, ends up being a
"humble request" for a network drive.

 But since reindexing doesn't solve the
problem I've since added a commit
whenever data is written to the LINES file.

Best to put this call outside any loops, to reduce processing time.
Say between the time you add the records, and the time you go to print
them. Or in long wait states, as a matter of course...

Good advice. Since this is an order entry application there is wait
time for the user to enter the next item so it's not a problem.

 I won't know if this addresses the issue
until I hear back from the users that it's
no longer happening.

OK. Fingers and toes crossed...

So... should I be using the commit opcode
after file writes?  And why would this
problem surface all of a sudden?  

You have my opinions above. As to what you *should* do, is you
*should* upgrade to (x)Harbour as a minimum step, so that you are no
longer running in the DOS box that Micro$haft is not offering on 64-
bit OpSys now. They are telling you they don't want to support DOS
apps anymore. So you should either listen to them, or only run true
DOS sessions.

I'm trying to hold out until retirement. Think I can go another 10
years? :)

Seriously, that's a large project that's hard to justify to the
client. The other issue is my skill set. My area of expertise is the
IBM midrange platform. Maintaining this POS system for one of my
clients is my only foray into PC programming. I imagine that most
conversions from Clipper to Harbour are undertaken by people with a
much broader PC background than I possess.

Splice from other post:
I'd suggest you CD to a different directory,
then come back to it without changing one
line of code.

Not sure what you mean here.

Just meant if you change to another directory, then come back, WinDoze
is forced to refresh its contents of date / time a particular file has
been touched. No big deal.

Ah... I see.
.

Relevant Pages

  • Re: Timing problem on file deletes
    ... Better to index LIN on ORDNBR, seek ORD->ORDNBR, and do while ORDNBR = ... OpSys is well behaved. ... where the "witchcraft" of deleting the index ... They are telling you they don't want to support DOS ...
    (comp.lang.clipper)
  • Re: Cannot explain why the date is changed to 1792.
    ... DOS specific stuff which makes it very ... There's no such struct in C thought if you supply the definition, ... For instance this won't read a string dd-mm-yyyy because for example ... admonition and helpful advice to the OP. ...
    (comp.lang.c)
  • Re: Word 2003 hangs on opening
    ... hangs. ... If I follow the main advice of deleting the normal.dot template then ...
    (microsoft.public.word.application.errors)
  • Word 2003 hangs on opening
    ... hangs. ... If I follow the main advice of deleting the normal.dot template then ...
    (microsoft.public.word.application.errors)
  • still probs trying to delete file
    ... You might want to try booting to dos and deleting the ... Also a trick the may or may not work is renaming ...
    (microsoft.public.windowsxp.security_admin)