Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Protecting Tables against power fail - FLUSH doesnt work
Message
From
19/11/2001 22:31:43
Malcolm Sheldon
Benchmark Consultants
Australia
 
 
To
15/11/2001 22:11:25
Malcolm Sheldon
Benchmark Consultants
Australia
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
00582519
Message ID:
00583753
Views:
20
Thanks for all the suggestions so far, unfortunately I've not had any success, but I know a few things that dont work. I've tried these thing under both Win2000 and Win95 standalone:-

1. BEGIN/END TRANSACTION around the INSERTS
2. Table Buffering on each table on opening and TABLEUPDATES before the END TRANSACTION
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. I just need to turn off any Windows caching, and force it to act like a DOS box.

This is a trial to establish the viability of creating a new Point of Sale system in VFP. In this context and 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.

I also took the test program and converted it to run under Foxpro for DOS 2.6 under Win2000, and guess what? It worked fine. I lost one record from one table, which is about what you'd expect.

How come old Foxpro for DOS can do it but super VFP7 cant??

ANY help would be gratefully accepted.

Regards

Malcolm Sheldon
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform