Page 1 of 1
WINDOWS XP DELAY WRITE
Posted: Sat Apr 17, 2010 7:07 am
by John Hohensee
I have been running a peer-to-peer network with five stations, NO SQL is used.
On a rare day we would have transaction get really crossed up.
Found that the default on Window hard drive write is over 30 minutes before a transaction is written to another station.
That is what was causing my transaction from getting crossed.
The time to write was verified by two transaction that occured over 30 minutes and got crossed.
Don't have the actual time the delay will hold a transaction from another workstation.
Turning OFF the WRITE CASHING - Q350174
Properites of My Computer -> HARDWARE -> PROPERTIES -> POLICIES -> DISABLE/ENABLE WRITE CASHING
Shows why a SQL is requred.
Because of the over 30 minute period that data can get really messed up due to the Hard Drive cashing default.
Re: WINDOWS XP DELAY WRITE
Posted: Sat May 01, 2010 5:56 am
by John Hohensee
My transaction would save to CUST.DBF then EQUIPMENT.DBF the WORKORDER.DBF the effect would show the EQUIPMENT.DBF had the data from the CUST.DBF.
In another procedure:
Save to PORDER.DBF save to POITEMS.DBF here the PO# would be crossed with another.
Turning OFF the WRITE DELAY stopped all this. Each workstation had to do it.
Re: WINDOWS XP DELAY WRITE
Posted: Wed May 26, 2010 6:22 am
by Auge_Ohr
hi,
i did read about Q350174, but i´m not shure if "disable" is good
while you also "touch" every other Win Application
did you try to reduce
DBFDBE_LIFETIME (DATA-Komponente) ?
I have been running a peer-to-peer network with five stations,
What OS() ?
seem me a Op´s Locking Problem ...
Re: WINDOWS XP DELAY WRITE
Posted: Sat May 29, 2010 12:01 am
by John Hohensee
All machines are using XP Pro. The length of time between first and second operation is what really got my attention, the time lapse of over 30 minutes from first and second machine saving a transaction.
Databases that are used for this transaction:
1. CUSTOMER - All information about the customer which includes a CUSTID
2. EQUIPMENT - All information about a piece of equipment owned by a customer includes CUSTID
3. WORKORDER - All information about a workorder, references to EQUIPMENT and CUSTOMER, includes CUSTID
NO I did not know about a dbf lifetime.
DBF DELAY WRITE SIMPLY COLLECTS DATA FROM THE ONE MACHINE AND WHEN ALL IS QUITE WILL WRITE DATA TO THE HD.
DOES NOT have adverse effect when the delayed write is ON or OFF no notice is apparent on any of the machines.
Re: WINDOWS XP DELAY WRITE
Posted: Sat May 29, 2010 8:44 am
by Auge_Ohr
John Hohensee wrote:All machines are using XP Pro.
so you are using SMB1
read about it on Alaska Website
http://www.alaska-software.com/ 25.06.2009
and download
ftp://ftp.alaska-software.com/documents ... ion-de.pdf
on Page 18/20 you will find
Code: Select all
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters\DisableFlushOnCleanup = 1
John Hohensee wrote:NO I did not know about a dbf lifetime.
this is a Parameter you can use in
DBESYS, look at
DATA Component.
your workaround might work with your P2P Machine, but not with 100 or more Workstation
i recommend to use Xbase++ and Alaska "Solution" on Client and(!!!) Server.
Re: WINDOWS XP DELAY WRITE
Posted: Fri Jun 04, 2010 3:45 pm
by sfsltd
Hi all
This is a long standing issue...
We do the following to minimise problems:
[*][*]open tables 'SHARED' wherever possible
This causes the application to re-check the lock status of the DBF before ever file access.
If you open tables EXCLUSIVE the application is 'faster' because won't re-check the lock state before each access. That's a bad strategy since NT4 SP4, since OPLOCKS are 'super-locks' that trump file locks (that's why Anti Virus uses them)
[*]use DBCommit() after EVERY write transaction.
This 'flushes' the entire disk cache... yes it flushes everything, not just your application.. but the overhead on the client is rarely noticeable.
.