Re: Bugg? in tableupdate - VFP8-SP1 by Mark
Mark
Thu Sep 01 11:45:12 CDT 2005
Hi Christina,
You might want to consider the FLUSH command, but please read on ( it's form
Hacker's Guide to VFP 7).
FLUSH empties all internal buffers of data (which have nothing to do with
record or table buffering) to be written to disk. Buffers are automatically
flushed when the table is closed or a record is unlocked.
In rare cases, the loss of a computer or the network before all disk writes
are completed can result in the loss of data within a record, or even the
corruption of a table header, leading to the dreaded "Not a table" error
message. Visual FoxPro and its immediate predecessors seem to be better at
this than the bad old days of dBASE III and FoxBase, but we're not sure how
much of this is due to improvements in the product and how much is due to
more reliable hardware and much more common UPSes. Also, new logic was added
into the process of opening a file in VFP, so that if it detects the header
is "one off" from the actual record count, it just increments the header
count, invisibly and silently, and continues the file-open process. In
addition, because releasing record and file locks automatically flushes the
data (although not the file headers), the increased popularity of rapid
lock-update-unlock techniques has probably also contributed to the overall
reliability of our systems. Row- and table-buffering techniques that also
commit data to disk as rapidly as possible alleviate most of the need for
this command.
However, in Doug's experience, buffering seems to update the data records,
but not always the table and memo headers. Even an explicit FLUSH may not be
the solutionâ??he reports that FLUSH updates the table and memo file headers
but not the CDX header. Closing a file, issuing an explicit FLUSH, or waiting
for the timeout for automatic flushing (we think that that is five minutes,
set internally and inaccessible to us) may still not be sufficient for the
most paranoid. Realistically, the command is a FoxPro solution for something
that is not a FoxPro problemâ??the problem is the environment in which you are
asking FoxPro to perform. If your network suffers frequent crashes, fix it.
Until you can, consider FLUSHes as a Band-Aid to lower the frequency of, but
not necessarily eliminate, file corruption. If the crashing can't be stopped,
consider a more robust data storage technique like client-server instead of
the direct writing to ISAM files of the FoxPro DBF model.
Forcing a FLUSH defeats the automated caching of Visual FoxPro and leads to
degraded performance. Because writes are performed automatically upon the
release of locks, the only situations in which FLUSH is likely to save more
data is where tables are being bulk-updated in an exclusive or file-locked
situation.
Bottom line: If you're losing a lot of data, you can use FLUSH to improve
the situation a little. But improving the online reliability of your system
will be a far better long-term investment. We don't use this command much at
all.
hth
Mark
"Ch Löfberg" wrote:
> You are observant Mark, good, yes I have been struggling with this on and
> off some time now. The problem is that llUpdated =
> tableupdate(1,.F.,lcAlias) returns .F. to llUpdated even after an
> update-success. The code is fired from an edtBox´s (source=memo) valid. The
> messagebox is fired and gives a false information to the user.This happens
> only if .fpt file is quite large - approx 10M. Smaller files - no problems.
>
> There is no difference if I put a Refresch() before comparing CURVAL against
> OLDVAL. lcAlias is a local rowbuffered view. lcFieldName is a memofieldname.
>
> The problem isn´t inside the else-code I didn´t show because I wanted to
> keep it short. But since you are asking, here is the else-code abbreviated;
> ELSE && curval differs from oldval - unother user has changed
> TABLEREVERT(.F.,lcAlias)
> MESSAGEBOX() && Mess to user - not saved
> ENDIF
>
> Best regards
> Christina
>
> "Mark" <Mark@discussions.microsoft.com> skrev i meddelandet
> news:5050E1A9-6CF3-4AFD-8CE0-FB4B535EDF9A@microsoft.com...
> > Hi Christina,
> > AFAIK, you posted a similar question some weeks/months ago.
> > The second part of your code is missing
> >
> > IF CURVAL(lcFieldName,lcAlias) == OLDVAL(lcFieldName,lcAlias)
> > llUpdated = tableupdate(1,.F.,lcAlias)
> >
> > IF llUpdated = .T.
> > wait 'Saved' nowait window
> > ELSE && i.e. unother user has removed the record
> > TABLEREVERT(.F.,lcAlias)
> > MESSAGEBOX('Save failed, record removed by unother user', ;
> > 0+48,'Securityinformation')
> > ENDIF
> >
> > Else
> >
> > missing code
> >
> > ENDIF
> >
> > hth
> >
> > Mark
> >
> >
> > "Ch Löfberg" wrote:
> >
> > > I have problems with tableupdate. Tableupdate returns F even after
> success.
> > > It happens if the field below is of type memo and the corespondending
> ..fpt
> > > file is quite large (10M). Small files - no problems.
> > >
> > > * write to table
> > > SET REPROCESS TO 3 SECONDS && 10 seconds is not better
> > > IF CURVAL(lcFieldName,lcAlias) == OLDVAL(lcFieldName,lcAlias)
> > > llUpdated = tableupdate(1,.F.,lcAlias)
> > >
> > > IF llUpdated = .T.
> > > wait 'Saved' nowait window
> > > ELSE && i.e. unother user has removed the record
> > > TABLEREVERT(.F.,lcAlias)
> > > MESSAGEBOX('Save failed, record removed by unother user', ;
> > > 0+48,'Securityinformation')
> > > ENDIF
> > > ENDIF
> > >
> > > The code above fires the messagebox. But if I continue to use the app I
> can
> > > see that the view´s sourcetable is updated after all.
> > >
> > > Hints about this should bee very appreciated.
> > >
> > > Best regards
> > > Christina
> > >
> > >
> > >
>
>
>