Board index » delphi » Help! Delphi 1 / Win95 Table Refresh Problem

Help! Delphi 1 / Win95 Table Refresh Problem

I have not had any problem with multi-user db apps in Win 3.x . . . I
have recently try to roll out one to a Win95 network . . . three
machines with one shared drive.  Aliases and .Net paths are correct . .
. the app runs fine except that the tables will not refresh for all
users unless everyone exits windows and returns to the application.  
Does Win95 actually cache the datasource?  Any help would be greatly
appreciated!

Thanks

Sam Jones (shjo...@fastlane.net)

 

Re:Help! Delphi 1 / Win95 Table Refresh Problem


In <31A3D726.6...@fastlane.net> SJones <shjo...@fastlane.net> writes:

Quote

>I have not had any problem with multi-user db apps in Win 3.x . . . I
>have recently try to roll out one to a Win95 network . . . three
>machines with one shared drive.  Aliases and .Net paths are correct .
>. the app runs fine except that the tables will not refresh for all
>users unless everyone exits windows and returns to the application.  
>Does Win95 actually cache the datasource?  Any help would be greatly
>appreciated!

>Thanks

>Sam Jones (shjo...@fastlane.net)

Following is an excerpt of an article that appeared a while back on
this group.  I must add that limited tests with WIN95 and a 16 bit app
does appear to lose data.  It would be nice if someone would put WIN95
through the grinder with some thorough testing and let us know.

*************************************************

It appears to be verified by Microsoft (obliquely) in Document Q110092.

Subject: Data loss: VCACHE with BDE, problem??
         Windows For Workgroups Caching Problem

This problem was discovered using Borland Delphi, however the engine
 is the same, and the same problem may be apparent on Paradox...

 We have discovered a problem where the WFWG 3.11  VCACHE caching
 mechanism appears to stop committing data to the local hard-drive
 and is lost following a hard reset or power-off. Disabling 32-bit
 access and using Smartdrv appears to correct the problem (see note 5).

Known factors:

(1) We have so far only observed the problem when the system is running
    our application which is written in Delphi 1.0 and uses the Borland
    Database Engine (BDE) ver 2.51a. Note: The BDE cache is NOT the
    cause of the data loss (see point 3). We have not been able to
    determine whether it also occurs without our application running.
    If our app or the BDE causes VCACHE to fail - we have not been
    able to determine how this occurs since it seems to happen
    somewhat randomly (?)

(2) A significant amount of data can be lost - even several hours worth
    - so this is not the effect of write-behind cached data that has
    not yet had the opportunity to commit at the time of reset. Our app
    can sit idle for an hour and still lose cached data.

(3) The Borland Database Engine caching mechanism is NOT responsible
    for the data loss.
      Evidence:
       -after each data post, each table in our app is closed and/or
          flushed from the BDE cache using the dbiSaveChanges engine
          call
       -data is also lost from text output files written to with the
          Pascal writeln command
       -data is lost from all other running apps (see Notepad example
          below)

(4) When VCACHE fails... all running apps fail to commit data to the
    local drive. We tested Notepad running concurrently with our app -
    periodically editing and saving a file from Notepad as we worked
    on our app. After reset data added after a given point in time is
    not included in the file. The time of failure to save data is the
    same time as for our app and all other running apps. The Progress
    Runtime client also acted this way in a similar test.

(5) When 32-bit file access is disabled, and only Smartdrv is used to
    cache data - this problem DOES NOT exist - even when write-behind
    caching is enabled (of course, in this case,  the last 5-seconds
    worth of editing will be lost). This suggests that even if our
    app or the BDE causes the failure, then VCACHE is somehow
    vulnerable in a way that Smartdrv is not. The problem does not
    exist in Windows 3.10 or 3.11 (non-Workgroups) - since these do
    not use VCACHE/32-bit file access. We have not tested the
    behaviour yet under Windows 95.

(6) We have identified this problem using two fairly different
    computer systems (one DEC and one Acer) - both running
    WFWG 3.11 on a Novell 4.10 network (all patches installed)
    with recent VLMs (version 1.20a).

(7) Data written to network volumes is NOT lost (of course, this
    data is not cached by VCACHE)

(8) All the running apps seem to behave "as normal". not reporting
    errors. Note: when the apps write data - they can re-read it
    back successfully even though this data will be lost after reset,
    therefore, the data does exist in the cache as valid data -
    the data just has not been flushed to the disk.

(9) The problem seemed to be connected to low USER resources (<40%)
    - however, we have reproduced it with fairly high (>55%) levels
    so we are not sure if there is really a connection.

 Does anyone recognize this problem ???

 Thank you, in advance, for any help.

Contacts:

amber_compu...@mindlink.bc.ca

     Ted Sorensen
     Systems Analyst / Programmer
     Amber Computer Systems Inc.

or   Dave Robinson
     VP Development

 Ph: 604 599-9167
 Px  604 599-9261

*************************************************

Other Threads