Re: dbf trashing problem after upgrade

Hi Anis
> i always issue flush
> commands at the end of every transaction to clean the buffers and
everything
> works perfectly well if the users exit the programs normally.

FLUSH doesn't work on disks that have an active Write cache, which is common
on Windows 2000 and XP an possibly other Windows versions. This feature can
be turned off but may reappear when the computer reboots.
Tha'ts why VFP in recent versions has added commands like SYS(1104) 'Purge
cached memory' and FLUSH FORCE to overwride the Write cache feature of the
OS.

When you say 'transactions' are you talking of transactions in general as
data modifications or as the BEGIN TRANSACTION - END TRANSACTION / ROLLBACK
commands in VFP?
-Anders


"Anis" <anis@xxxxxxxxxx> wrote in message
news:ucven0rOFHA.3880@xxxxxxxxxxxxxxxxxxxxxxx
> thanks for your reply brett,
>
> the vfp version of the application uses almost the same code and the same
> business rules as the old one. the only changes that have taken place are
> the platform (fpw26 to vfp7) and the os (98se to xp). i always issue flush
> commands at the end of every transaction to clean the buffers and
everything
> works perfectly well if the users exit the programs normally. i also set
> refresh to 5,5 to periodically update the tables as i used to do in fpw26.
> my big problem is with recovery anytime a crash occurs (crash here being
> that somebody turns off the central ups by mistake and all systems turn
off
> or even if the server crashes or restarts by mistake due to a user error)
> previously (fpw26 with foxfix on win98 se), anytime any of this happened,
> the application would automatically correct the files with foxfix and no
bad
> records (garbage) are appended to the file (the last transaction before
the
> flush usually gets lost). but now, with vfp7 running on xp, i always get
the
> garbage plus a lot of damaged records. could this be a problem with vfp7
and
> xp ? or possibly a problem with the way xp manages memory related to
foxpro.
> i have noticed that problems are less likely to occur on win2000 machines
> but they do occur nonetheless.
>
> anis
>
>
>
> "Brett Wickard" <nospam-bullmoose-nospam@xxxxxxxxxxx> wrote in message
> news:%23K%23BkgrOFHA.524@xxxxxxxxxxxxxxxxxxxxxxx
> > Wow, that sounds like a frustrating problem. I also develop POS
solutions
> > and have had very, very good luck with database integrity. On the store
> > level, the terminals share a DBF on the server. I would absolutely make
> > sure the server is running an NT kernel based O/S (i.e. NT/2000/XP). I
> > have had excellent results with NT kernel based, but 98 was so unstable
as
> > the file sharing server that we dumped it years ago. As for the POS
> > terminals themselves, I do allow clients to have old O/S's running the
> > software, and again, if the file server is running a good O/S and has a
> > good UPS, corruption should almost never happen.
> >
> > If you give me a few more details about your topology/setup of your
sites,
> > I might be able to offer advice that will help. Or I'll rant about
> > something that doesn't help and will just takeup bandwidth :)
> >
> >
> > "Anis" <anis@xxxxxxxxxx> wrote in message
> > news:%23t$fl5pOFHA.3000@xxxxxxxxxxxxxxxxxxxxxxx
> >> greetings to all,
> >>
> >> we have been loyal foxpro users for 12 years now and have developed
> >> various point-of-sale applications by using forpro 2.6
> >> for windows. our pos applications run on windows 98 se and in most
cases
> >> run in a network environment with at least 3 users
> >> and above. due to the nature of foxpro dbfs and the serious issue of
dbf
> >> files being trashed which especially occurs when the
> >> ups system goes down unexpectedly or when the server (also a win98 se
> >> machine) crashes, we extensivley used foxfix to remedy
> >> any issue automaticallty from the software and things seemed to work
> >> great 99.99% of the time all in all resulting in a very
> >> stable and recoverable application that made our clients very happy and
> >> our support staff glad.
> >>
> >> last year, we converted one of our pos applications to vfp7 sp1
(running
> >> on windows xp) and since we were loyal foxfix users,
> >> we purchased foxfix 5.2 in order to obtain and attain the reliablity
> >> which we were accustomed to from the marriage of fpw26
> >> and foxfix in our suite of applications. but things now seem to have
> >> changed. any time a crash occurs - for example the ups
> >> system goes down - foxfix is able to make all dbfs usable after a total
> >> system restart, but now opening any dbf file which is
> >> updated extensivley by the application (the sales file for example) and
> >> setting the order to the primary index tag yields
> >> tons of trash records at the beginning and the end of the dbf in the
> >> browse window. this case almost always happens when any
> >> crash of either the ups or the server occurs. what surprised us is that
> >> this EXTREMELY RARELY occured with our old version!
> >> what is also funny is that in most cases, no data seem to have been
lost
> >> (except for the cases of partial record trashing),
> >> only garbage gets appended to or inserted into the dbf from an unknown
> >> source.
> >>
> >> We have reused 95% of the code in our old application and the business
> >> logic is still the same. we do not use any buffering,
> >> or transaction tracking. all updates to the dbf are directly written
> >> followed by a flush command in the unload method of each
> >> form - the same way as we used to do before. also, we use the same data
> >> session for all the application and all dbf files are
> >> opened at the start of the application and are closed when the
> >> application terminates.
> >>
> >> when you upgrade a development platform, you expect all the niceties
and
> >> advantages and reliability that comes with the term
> >> UPGRADE. what you dont expect is going a couple of steps back with an
> >> upgrade of at least 4 versions forward (fpw26 to vfp7),
> >> and at least 2 upgrades forward for the os (win 98 se to winxp). but
then
> >> again, we might have made a mistake somewhere.
> >>
> >> i would appreciate any help or feedback regarding this issue and i
thank
> >> all those who reply to this post in advance for
> >> their help and for sharing their experiences.
> >>
> >> regards
> >>
> >> anis
> >>
> >>
> >
> >
>
>

.

Relevant Pages

  • Re: dbf trashing problem after upgrade
    ... i will do some testing with the commands you mentioned and let you know of ... > Hi Anis ... > FLUSH doesn't work on disks that have an active Write cache, ... > data modifications or as the BEGIN TRANSACTION - END TRANSACTION / ...
    (microsoft.public.fox.programmer.exchange)
  • Re: Transaction.Commit() and Transaction.Rollback()
    ... They are used to ensure that an entire group of commands succeeds or else none of them succeed. ... This is done through the use of a transaction log. ... The Begin Transaction, Commit Transaction, End Transaction & Rollback Transaction commands are ways to specify which groups of queries to treat as Atomic. ... Commit & End Transaction tells the database that your are finished with that atomic operation and that all the commands you had sent since the trasaction began should now get committed to the actual database tables. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Typed Dataset and transactions in ADO.NET 2.0
    ... Maybe this style...just across a couple of commands ... SqlTransaction trans; ... bReturnLog = ErrorLog.ErrorRoutine; ... I have a general question about typed datased and transaction. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Transaction and commands question
    ... What this will do is extract commands from a transaction logged in the log ... reader as they are found and send them to the distribution database. ... commitbatchsizethreshold. ...
    (microsoft.public.sqlserver.replication)
  • Re: FLUSH [was: Mixed language programming Tcl/Tk and Fortran (Windows)]
    ... of never omitting a flush that's needed). ... after all WRITEs that belong to one transaction. ... > run-time system determine where one transaction ends, ... A flush after *every* WRITE is sufficient to guarantee correctness. ...
    (comp.lang.fortran)