Re: dbf trashing problem after upgrade
- From: "Anis" <anis@xxxxxxxxxx>
- Date: Tue, 5 Apr 2005 17:33:11 +0200
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
>>
>>
>
>
.
- Follow-Ups:
- Re: dbf trashing problem after upgrade
- From: Anders Altberg
- Re: dbf trashing problem after upgrade
- From: Dennis P . Harris
- Re: dbf trashing problem after upgrade
- References:
- dbf trashing problem after upgrade
- From: Anis
- Re: dbf trashing problem after upgrade
- From: Brett Wickard
- dbf trashing problem after upgrade
- Prev by Date: Re: Help With Trapping Lock File Errors
- Next by Date: Re: Help With Trapping Lock File Errors
- Previous by thread: Re: dbf trashing problem after upgrade
- Next by thread: Re: dbf trashing problem after upgrade
- Index(es):
Relevant Pages
|
