WINDOWS XP DELAY WRITE

[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.

[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.

[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 ...

[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.

[Auge_Ohr]

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/xpp-compilation-de.pdf
on Page 18/20 you will find

Code: Select all

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters\DisableFlushOnCleanup = 1

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.

[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.

Code: Select all

&cFilename->( DBCommit())

.