Inconsistant data writes (AREV Specific)
At 16 MAY 2002 10:03:33AM Stuart J White wrote:
I have a well established AREV2.12 system that has reciently been installed at a new site.
The system, a factory control system, automatically flags internal an external order records when they have been printed. However, at this new site, these flags are not consistantly being set.
I have not been able to identify any other areas within the system where there are write failures, however, it is only business critical areas that the users tend to notice.
The system setup is win 95 workstations running against an NT server. The NT performance pack has been installed and we are using the all networks network driver v.1.5.0.0
I have previously posted regarding this problem, however, nothing suggested helped. I'm at a loss so any help would be greatly appreciated.
At 16 MAY 2002 10:52AM Don Miller - C3 Inc. wrote:
Suggestions:
1. Make sure Write-Behind caching is turned off on ALL client desktops. If you don't know how to do this, do a search for "Write Behind"
2. Do you have an ELSE clause after the write statement to catch the possibility that the WRITE fails for whatever reason.
3. Is the field in question INDEXED? Sometimes the data record is written but the index write / update fails.
Otherwise, don't know what to suggest.
Don Miller
C3 Inc.
At 16 MAY 2002 02:59PM Richard Hunt wrote:
The system, a factory control system, automatically flags internal an external order records when they have been printed. However, at this new site, these flags are not consistantly being set.
Stuart,
If you can explain in detail what you mean by "automatically flags" it would help. Does it do it by indexes or by writes? Does it flag it in the same row (record) in the same table (file)? Or does it update a seperate table (file)?
If it is updating NOT using indexes… are you locking the row (record) before the write?
At 16 MAY 2002 06:43PM Dave Harmacek wrote:
It is my experience that because of the variable-length nature of Linear Hash files "write failures" affect the files in a rather drastic way. That is, not in specific fields or particular records. These "drastic problems" quickly appear as GFE's.
So, in your case I suggest you look for logic that allows records to be rewritten with the original data instead of containing the update you expected.
Dave
At 16 MAY 2002 10:14PM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
Are there any MFS's on the files concerned? We've seen faulty MFS code that causes this effect.
Are you certain that all workstations are using the correct and the same network drivers?
Check the indexing updates are being carried out. We have seen low memory cause indexing to do strange things. Enable expanded memory on all workstations. Ensure that "exclusive in foreground" is *not* set on the Windows shortcuts.
Do you have multiple copies of AREV.EXE about the site, all attaching to the one database?
If you use a lot of select-based processes for batch updating
then try attaching LISTS files situated on your C:\ drive.
We've seen this many times before on Win 95.
You might try increasing the file handles on the workstation also.
It could be time to drag your client's operating systems kicking and screaming into the 21st century.
[i]Celebrate CeBIT with Sprezz Local![/i]
