HELP - VFP and Power Fail - FLUSH Doesnt work
Malcolm Sheldon
a new Point of Sale system. One of the concerns is its behaviour when
there is a power fail.
I started by writing a test program which opens 6 tables, then in a
loop 1 TO 2000 adds one record to each table then FLUSHes the buffers,
then goes round again.
Whilest in the loop I switch the power off. On restart I then see
what has ended up in the tables.
I run this program under Win2000 and Win95
Under FDP2.6 DOS, I get nearly all records into the tables. I may lose
1 record from 1 table, but the results are pretty well what I would
expect.
BUT, under VFP6/7 very different things happen. I can get just about
any number of records into the table, and have a different number in
each table, 100's of records get "lost".
This is what I've tried so far without success:-
1. BEGIN/END TRANSACTION around the INSERTS
2. Table Buffering on each table on opening and TABLEUPDATES before
the END TRANSACTION
Then I tried a few stranger things suggested by various people.
3. SYS(1104) to flush the VFP Buffers
4. RLOCK/UNLOCK after the END TRANSACTION
5. Changing the INSERT INTO, to an APPEND BLANK/GATHER MEMVAR
6. Open the tables AGAIN, GOTO (RECCOUNT()) and replace a field with
its current contents.
7. Call the FlushFileBuffers API call for all file handles 1 TO 50
8. Turned off the Disk Caching in Windows, device manager.
All of which seems to make no difference at all. I think that it is
Windows that is "sitting" on the data and not pushing it out to the
disk quickly enough.
I cannot find a way of truly Flushing the data to the disk.
In the context of a POS application, given this scenario, data from
sales hours ago could be lost not just the current sale if there is a
power outage. I dont mind losing the current transaction, but old
data thats just waiting to be committed is unacceptable.
Does anyone have a clue as to what is happening, and how can I force
the flush to physically happen, and stop the application until its
complete?????
How come old Foxpro for DOS can do it but super VFP7 cant??
ANY help would be gratefully accepted.
Kind Regards
Malcolm Sheldon
Craig Berntson
using buffering? Are you using the exact same hardware with the DOS program?
--
Craig Berntson
MCSD, Visual FoxPro MVP
www.craigberntson.com
Salt Lake City Fox User Group
---
"Malcolm Sheldon" <bnch...@ozemail.com.au> wrote in message
news:50356c40.01111...@posting.google.com...
Oliver Birdsong
Welcome to the Wunnerful Worl' uv Windoze!
I presume you're writing records to a local drive, not through a network or
anything. Windows works it's wonders by the abuse of buffers. Lots of
them. But since you can't switch to a different operating system, here are
some suggestions:
Make sure that table buffering is disabled. You've probably already done
this, but check it anyway.
Close and open the data file. Closing the file should trigger the OpSys
buffers to write data to the disk.
Compare the other products with VFP on a power outage scenario. If the
others are running on Windoze, they won't perform any better. Of course, if
another product does consistently perform better you can probably deduce
what's happening and apply it to VFP.
Put users on a UPS. If it's a POS system, they should probably be on a UPS
anyway.
I find this research you're doing very interesting, and would like to know
the final results. Please keep me posted. Thanks!
Paul Lee
news:50356c40.01111...@posting.google.com:
> ..........
> I cannot find a way of truly Flushing the data to the disk.
>
FLUSH may not work with table buffering. FLUSH should work if
you use the old style FP2X default buffering mode in VFP. Also it
is advised to turn off write ahead caching on all of your PC's
used in the app.
-----------------------------------------------------------------
Paul Lee ........... Abri Technologies ......... http://abri.com/
'Recover' - top rated FoxPro file repair utility.
-----------------------------------------------------------------
Malcolm Sheldon
Up to today, I have been doing most of my testing under Win2000,
(which is our prefered platform), I tried Win95 in the early days, but
hadnt gone back to it. I realised I hadnt tried the turning off of
the Windows disk caching on 95. When I did this my test program
worked. I've now stripped back my test program to just use one FLUSH
after the END TRANSACTION, and it gives results pretty close to my FPD
version, with caching off under '95.
HOWEVER, under Win2000, although I turn off caching, (which is under
the actual disk properties in Device Manager), it DOESNT stop Windows
from caching the data, and I lose records no matter what I do.
Although this may be the disk caching for the hardware itself, not the
Windows caching. I cant find anywhere else that allows switching off
of caching in Win2000.
Looking through the Microsoft KB, I've found a known bug which says
that disk caching is always put back on when Win2000 starts up, no
matter what you set it to. This isnt quite the same problem, but
sounds close, so I've requested Microsoft email me the patch, which
isn't on general release yet. I expect to get this next week, I'll
let you know what the result is.
Many thanks for all your suggestions, I've certainly learnt a lot
during all my tests.
Kind Regards
Malcolm Sheldon
Rick Bean
Check out http://support.microsoft.com/support/kb/articles/q129/2/02.asp -
"PC Ext: Explanation of Opportunistic Locking on Windows NT". While it says
it's for NT, I believe the same settings exist for W2K and XP.
Rick
"Malcolm Sheldon" <bnch...@ozemail.com.au> wrote in message
news:50356c40.01112...@posting.google.com...
Malcolm Sheldon
the keys in the article, but it didnt make any difference. In my test
I just run W2K in stand alone, with the tables on C:, so it may not be
used.
Windows just doesnt want to write the records away until the
application closes, or Windows shuts down. If I power off from the
power switch, then windows will detect this and power down nicely,
flushing everything to disk before it allows power to shut off. BUT
if I switch off at the mains, I lose 100's of records, which
presumably were still sitting in buffers waiting to be flushed to the
disk.
I'm still searching for a way to make W2K behave like DOS or Win95,
which I know handle this OK.
I cant believe I'm the only person to have found this problem?
Perhaps everyone else lives in a world where power is always on, or
they have UPS's?
Malcolm
Frank Dietrich
Malcom,
On 19 Nov 2001 18:47:30 -0800, bnch...@ozemail.com.au (Malcolm Sheldon) wrote:
>I am trying to prove that VFP is a resilient development language for
>a new Point of Sale system. One of the concerns is its behaviour when
>there is a power fail.
I am using a POS-System with Fox since '94. Up to two months ago it still had been
FPW2.6 now I was very keen to directly "relaunch" it under VFP 7.
Since all theese Years I never really had any severe Problems though we (the customer) did not
use UPS-Systems and not seldom used the old PC's for the task.
I was thinking long about directly using VFP7 for the new creation but up to now
the system is running georgious.
But what I found out over the years was the following (especially when running FPW26 under
a 32bit System):
- Depending on the load (usage) of the POS-System, we every 5, 10 20 or in whatever interval
we do close all relevant tables and reopen them because otherwise You indeed get unpredictable
results in what is left and what not (if You are connected to a network ?!). Flush is not really doing
any good.
- We do everything in a temporary cursor upt to the point the sales-operation is finished.
At that point we request the new receit No. and start to update the sales and stock-Tables - all
buffered. when this is done whe have all the information in the buffers. We start a transaction and
write out to disk. If anything (normal) happens we rollback and inform the user to try again in a second
as the whole operation is in a temporary table (that is not buffered) every detail is still there.
You could even shut down the computer and restart. The temporary file is connected to the userID,
so when the user restarts the system the case is brought up again and can be continued.
When the Transaction passes through, the receit is being printed. But to be sure we do not print
it from the actual case (the temp cursor) but directly from the just saved "real" files.
So the worst thing that can normally happen is that the current operation has to be redone. However
You never have the problem asking, "witch of my three articles has been saved and witch not?".
By reducing the actual saving to 1 per case and surrounding that by a transaction, the case has either
been saved completely or not at all.
- As a backup (and for additional information) we always write detailed protocols (journals) into text files.
The action is written there AS it happens. So You can see the whole history of a case. An article
has been added, then the price as been reduced because ..., another Article added, the first one
deleted, Payment via Creditcard, logoff, logON .... and finally every important step. So You will
find "Saving receit No. 123456" and if the save-process passes "Receit 123456 successfully saved".
or "Starting to print receit 123456" and "Printing Receit 123456 done". By that way You can really
see where the system crashed.
Theese files have up to today been accurate even at the hardest crashes (They are not being kept
open after writing).
- We have other redundancy and security checks like an exit Flag. If the application is just terminated
and not properly exited The user will be prompted to perform a data-check-Operation.
"The last exit seemed to pe abnormal. A data-Check-Routine will be started now..".
There we do check if all the tables are OK (we have FOXFIX in the background for this) and all indices
are being DELETED (ERASED!) and recreated. At that point one could even open the protocol-file
and check for the last receit and reprint it (Asking the clerk "Was this Your last case?").
- And finally REDUNDANCY , REDUNDANCY and sometimes REDUNDANCY
Regards from Berlin
Frank
Dietrich Datentechnik (Berlin)
Softwarekombinat Teltow (Teltow)
Frank.D...@dd-tech.de
DFPUG # 327