Re: Compiler doesn't seem to work properly at all times

From: Anynomous (wipeout64_at_hotmail.com)
Date: 11/04/04


Date: Thu, 04 Nov 2004 18:07:10 GMT

I just learned that not using the project hook causes this. I suppose this
means a re-write of the entire app? I was converting non-visual code to
visual foxpro which is why I didn't use a proj. hook

"Dan Freeman" <spam@microsoft.com> wrote in message
news:%23q0KD8owEHA.1092@TK2MSFTNGP10.phx.gbl...
> Well, let's boil down the symptoms: something is preventing your changes
> from being written to disk, and it's a problem that is not often reported.
>
> What can prevent disk writes? Anti-virus software actually has that as
part
> of its job. <g> Likewise disk caches (turn off write-ahead cacheing --
it's
> on by default).
>
> What else is unique about your environment that's giving your this unique
> behavior?
>
> Dan
>
> Anynomous wrote:
> > This sounds like a good guess, but wouldn't everyone have this
> > problem if it were the antivirus software? It was on someone else's
> > machine when I first discovered that my changes were not being saved
> > properly and it wasn't even the same application that I normally work
> > with. My antivirus software doesn't allow me to choose what file
> > extensions to ignore.
> >
> >
> > "Dan Freeman" <spam@microsoft.com> wrote in message
> > news:u5X03ScwEHA.2600@TK2MSFTNGP09.phx.gbl...
> >> I've never experienced that.
> >>
> >> Do you have VFP file extensions excluded from your anti-virus
> >> program?
> >>
> >> Dan
> >>
> >> Anonymous wrote:
> >>> In version Visual FoxPro 7.0, the compiler doesn't always seem to be
> >>> doing it's job. I've noticed this also in version 6.0 regardless of
> >>> the service packs. Well, frequently I dismissed it thinking perhaps
> >>> it's an error in code or I changed something that effected it. Well,
> >>> just the other day I simply took a label off of a screen and I
> >>> thought I deleted all references to it. Ran the screen several
> >>> times with no problem. Either later in the day or the next day, I
> >>> ran the screen and received an error that I had not deleted a
> >>> reference in the init of the screen. Regardless of what I had done
> >>> in the screen, the reference in the init error should have
> >>> displayed. It was a plain no conditional reference. I did notice in
> >>> version 6.0, changes that I had done seemed to be undone after a
> >>> few compiles. I stopped this from occurring by deleting the .bak
> >>> files frequently. Well I have the .bak file option shut off in
> >>> version 7.0. It seems that the files in the background (screens can
> >>> be treated as tables like the reports), these changes aren't saved
> >>> properly or permanently for some reason. Anyone else experienceing
> >>> this? Anything I can do about this? It's embarassing and I can't do
> >>> my job properly if I have to be my own manual compiler!
>
>



Relevant Pages

  • Re: Need guidance diagnosing increasingly slow PC. Must Win2k typically be reinstalled each year?
    ... >utilities etc. that install background services or processes ... >(e.g. antivirus software is notorious for this), ... >IDE driver update that switches data transfer mode from ... Normal disk fill-up. ...
    (microsoft.public.win2000.general)
  • Re: Recorded TV Skipping Problem
    ... It would obviously matter if your antivirus software is checking all disk ... transfers since in the situation you describe the system is apparently ... >>> I start recording a 1 hour show without watching the program. ...
    (microsoft.public.windows.mediacenter)
  • Re: Compiler doesnt seem to work properly at all times
    ... let's boil down the symptoms: something is preventing your changes ... from being written to disk, and it's a problem that is not often reported. ... Dan ... My antivirus software doesn't allow me to choose what file ...
    (microsoft.public.fox.vfp.dbc)
  • Re: Run-away Logs
    ... I'm presuming you're running proper online backups of your stores during the ... Remember that any file-level antivirus software must be setup to exclude at ... > Exchange log files are filling up our C: disk every ...
    (microsoft.public.exchange2000.general)