Memo Files Keep Getting Corrupted - Help
MikeA
corrupted now everyday. I can't seem to figure out why. I fix it by taking
a blank table and appending all the records from the corrupted table to the
blank table. The file reindexes fine but if I do a Pack Memo then it gives
a "memo file is xxx.fpt missing or invalid"
I have tried almost everything from changing the cables, hubs, routers and
still the problem continues. They only have about 8 workstations on their
server so it is not a large network. I have many other clients and none
have this problem. I've tried substituting out the server for another
server (just a simple Win 98 server) and that did not fix the problem
either. However, it does seem that other tables with memo files (although
not used as much in the program) also are vulnerable to this problem. The
problem started a few months back. They had been using the program for
years without this problem and many other clients of mine use it with no
problems like this at all.
What can cause a memo file to keep getting corrupted like this?
Thanks,
Mike
Roger Ansell
"MikeA" <app...@appellsoftware.com> wrote:
See if either of these help:
http://support.microsoft.com/kb/264867
http://support.microsoft.com/?id=812696
-Roger
OlivierH
My tips,
* ==================================================
* Proc fix memo invalid or Missing
* ==================================================
LParameters merreur,mmessage,mprogram
Set tablevalidate to 0
If merreur = 41 && Memo file "name" is missing >or is invalid (Error 41)
cAlias = ALIAS()
ALTER TABLE ( cAlias ) ADD COLUMN Leurre M NULL
ALTER TABLE ( cAlias ) DROP COLUMN Leurre
EndIF
If you want test
Set tablevalidate to 0
Try
m.cAlias =Alias()
PACK IN (m.cALIAS)
Catch to m.oErr
If m.oErr.ErrorNo = 41 && Memo file "name" is missing >or is invalid
(Error 41)
ALTER TABLE (m.cALIAS) ADD COLUMN Leurre M NULL
ALTER TABLE (m.cALIAS) DROP COLUMN Leurre
PACK
EndIF
EndTRY
Olivier
MikeA a écrit :
--
================================
Olivier Hamou
Vfp9 sp1 - Winxp sp2
================================
Ook
> server (just a simple Win 98 server)
You are hosting the files on a Win98 "server"???? Consider yourself
fortunate that it ever worked at all. If I had a client hosting files on
a Win98 box, I would refuse to help them until the replaced it with a
Win2k+ box. You've probably heard this before, but hosting files on a
Win98 box is an extremely bad idea, and is file corruption just begging
to happen.
What OS are the workstations using? Are you absolutely positive that
there isn't a user that is resetting their workstation, or having the OS
crash or otherwise preventing VFP from shutting down normally? Does this
happen at a certain time of day? When a certain user is there or does
something? Have you spent a few hours there just observing? When you
quietly watch the users in action, you can learn all kinds of things
about what they do, what works, what doesn't work, and you just might
catch that one person that likes to press the reset button every hour on
the hour.
Gene Wirchenko
>"MikeA" <app...@appellsoftware.com> wrote:
[snip]
>> What can cause a memo file to keep getting corrupted like this?
>
>See if either of these help:
>http://support.microsoft.com/kb/264867
One of the items is:
"File locking issues: If one user performs an action that results
in a table's memo file being locked, and a second user attempts to
open the same table and access the memo field information, the second
user may open the memo file with an incorrect blocksize, resulting in
memo file corruption. See the "References" section in this article for
details."
This is scary. None of the references seem to deal with this.
Does anyone have more data on this?
>http://support.microsoft.com/?id=812696
Look at these two sentences from the second reference: ". . .they
may receive the following error message, even though there is nothing
wrong with the memo file:" and "This behavior is by design." GAH!
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
MikeA
real winner. I think that just may be where the problem lies. I have had
lots of clients in the past run Win 98 as a server without any problems
ever. In fact, what did we all do before windows 2000 anyways? This one
client of mine had been running this same server for years without any
problems. Then a few months back when they started upgrading some
workstations to XP, that's when the problems started. I never thought about
different file locking schemes between XP and 98 on a 98 server. I'll
definitely have them check into that.
One benefit of 98 as a server was the unlimited number of workstations one
could attach to it (unlike XP). Seems like Microsoft will do anything to
get everyone to upgrade. In any event, regarding the other article, I don't
worry about that much because in my application I always check to see if I
can do a lock before modifying any records in a simple procedure.
QUESTION: Do you know if running a Windows 2000 server (some of my clients
have that) could cause locking conflicts if they have a mixture of
workstations with 98, 2000 and XP?
Thanks again,
Mike
"Roger Ansell" <no...@realemailaddress.net> wrote in message
news:eEs0SYhu...@TK2MSFTNGP05.phx.gbl...
MikeA
http://support.microsoft.com/?id=812696
It says under symtoms, "You use a computer that is running Microsoft Windows
Millennium Edition or an earlier version of Windows as a file server. That
computer hosts Visual FoxPro tables that contain memo fields. When users
with computers that are running Microsoft Windows XP try to access these
tables, they may receive the following error message, even though there is
nothing wrong with the memo file:"
It does say this (especially when doing a pack memo). But, the memo file IS
getting corrupted and it's as if memo records are being saved over other
memo records. Would this be caused by the Win 98 server and XP workstation
locking conflicts?
Does anyone think Microsoft changed the locking schemes on purpose?
Thanks,
Mike
"MikeA" <app...@appellsoftware.com> wrote in message
news:K6bhi.13$Np2.6@trnddc07...
Dan Freeman
system. Novell was another common *SERVER* operating system.
Windows 98 is NOT a server operating system. Nor is Windows XP. Those are
workstation operating systems.
Your file server should be running a *SERVER* operating system.
We had a client that tried to use XP as a server. We got so many support
calls we refused to take them until they replaced it with a *SERVER*
operating system. Not surprisingly, they stopped NEEDING support calls once
they did.
Dan
Paul Pedersen
"Roger Ansell" <no...@realemailaddress.net> wrote in message
news:eEs0SYhu...@TK2MSFTNGP05.phx.gbl...
>
I just love the status in the second one: "This behavior is by design."
Yes, get rid of the Win98 box. Network problems can also cause this.
Paul Pedersen
"Dan Freeman" <sp...@microsoft.com> wrote in message
news:eypKI$nuHH...@TK2MSFTNGP06.phx.gbl...
> Before Windows 2000 *SERVER*, most of us used some other *SERVER*
> operating system. Novell was another common *SERVER* operating system.
>
> Windows 98 is NOT a server operating system. Nor is Windows XP. Those are
> workstation operating systems.
>
> Your file server should be running a *SERVER* operating system.
>
> We had a client that tried to use XP as a server. We got so many support
> calls we refused to take them until they replaced it with a *SERVER*
> operating system. Not surprisingly, they stopped NEEDING support calls
> once they did.
>
> Dan
Well, there goes all your business...
Roger Ansell
"Paul Pedersen" <nos...@no.spam> wrote:
[snip]>> See if either of these help:
>> http://support.microsoft.com/kb/264867
>> http://support.microsoft.com/?id=812696
>>
>> -Roger
>
> I just love the status in the second one: "This behavior is by
> design."
LOL!
There's also a link in the first to:
http://support.microsoft.com/kb/193952/
It starts with "When you use Microsoft Visual FoxPro,
you may sometimes run into problems."
I don't believe it. <s>
-Roger
MikeA
> you may sometimes run into problems."
Does this mean that Microsoft may purposefully at some point create new
windows OS so as to not support VFP?
Mike
Is will the Microsoft
"Roger Ansell" <no...@realemailaddress.net> wrote in message
news:ejn9y$ouHHA...@TK2MSFTNGP03.phx.gbl...
Paul Pedersen
Yeah, that's a good one. And it's followed by "The cause of these problems
is not always immediately clear."
All in all though, I have to say that I've been content with FoxPro. It's
capable of some pretty amazing things, things I tried and failed to do in
VB, and I'm sorry that future development has been halted.
Roger Ansell
"Paul Pedersen" <nos...@no.spam> wrote:>
>> There's also a link in the first to:
>> http://support.microsoft.com/kb/193952/
>>
>> It starts with "When you use Microsoft Visual FoxPro,
>> you may sometimes run into problems."
>>
>> I don't believe it. <s>
>>
>> -Roger
>
> Yeah, that's a good one. And it's followed by "The cause of these
> problems is not always immediately clear."
>
> All in all though, I have to say that I've been content with FoxPro.
> It's capable of some pretty amazing things, things I tried and failed
> to do in VB, and I'm sorry that future development has been halted.
Yup ... I'll second all of that.
Remember when MS was canvassing (or *said* they were canvassing)
the VFP community about whether or not VFP should be included
in the .Net framework? AFAIR, the official line was if VFP
was included in .Net, we'd lose VFP's data engine. So, of course,
almost everyone who was canvassed said "no way".
It's a pity MS didn't tell us back then that if VFP was excluded
from .Net, its future was doomed. But there again, I expect MS
knew the answer and it would have made no difference either
way. <sigh>
-Roger
MikeA
Is it because they want to force users into a more expensive solution like
SQL? On a more hopeful front, I think there is still a large newsgroup out
there for Clipper (dBase compiler for DOS). It's still around even though
there are no updates for the language and I programmed in it before I got
into VFP years ago. DOS die hards I guess. As long as Windows OS continues
to run VFP products, I'm sure we'll all continue to program in VFP.
Any comments?
Mike
"Roger Ansell" <no...@realemailaddress.net> wrote in message
news:Oa37hSzu...@TK2MSFTNGP04.phx.gbl...
Paul Pedersen
> Why does Microsoft provide such little support for a great product like
> VFP? Is it because they want to force users into a more expensive solution
> like SQL?
Probably. Also, as I understand it, FoxPro does not generate managed code,
so is inherently less safe than dotnet code. And making it do so will be
difficult or impossible. In particular, macro substitutions are a problem,
because it cannot be determined at compile time what the code will do. And
without those, FP will lose a lot of flexibility, and a large amount of
legacy code will no longer run. (I use them only rarely, but when they're
needed, you can't beat the convenience.)
> On a more hopeful front, I think there is still a large newsgroup out
> there for Clipper (dBase compiler for DOS). It's still around even though
> there are no updates for the language and I programmed in it before I got
> into VFP years ago. DOS die hards I guess. As long as Windows OS
> continues to run VFP products, I'm sure we'll all continue to program in
> VFP.
>
> Any comments?
>
> Mike
After learning VFP, I never went back to FPW or FPD, and for good reason. It
was a huge improvement! I'd rather continue using Visual FoxPro as it is and
will be, than go back to a DOS program. Ick.
Roger Ansell
"MikeA" <app...@appellsoftware.com> wrote:
> Why does Microsoft provide such little support for a great product
> like VFP? Is it because they want to force users into a more expensive
> solution like SQL?
There's been much debate about this over the years. MS's logic
is beyond my reasoning, however if the reason was to push the
more expensive solution (SQL Server + VB), it only proves how detached
MS is from the application development community.
For one, there's no way I would recommend using MS SQL Server
under any circumstances in a client/server scenario. There are
better cost-effective alternatives (eg MySQL).
> On a more hopeful front, I think there is still a large newsgroup out
> there for Clipper (dBase compiler for DOS). It's still around even
> though there are no updates for the language and I programmed in it
> before I got into VFP years ago. DOS die hards I guess.
I agree with Paul. No way I'm going backwards.
> As long as Windows OS continues to run VFP products, I'm sure we'll
> all continue to program in VFP.
Aye but we'll be increasingly irrelevant. No new enterprise systems
will be written in VFP and existing ones will gradually be
re-written in dotNet. I'll continue to use VFP for non mission-critical
apps with a lifespan of around 5 years or less and for prototyping.
But seriously, how can you justify application development in VFP
to your customers when MS has publicly stated that there will be
no more development of the product beyond SP2?
-Roger
MikeA
>> there for Clipper (dBase compiler for DOS). It's still around even
>> though there are no updates for the language and I programmed in it
>> before I got into VFP years ago. DOS die hards I guess.
>
> I agree with Paul. No way I'm going backwards.
What I meant by that post was that I think VFP programmers will be around
for a long time (as there are still Clipper developers).
>
>> As long as Windows OS continues to run VFP products, I'm sure we'll all
>> continue to program in VFP.
>
> Aye but we'll be increasingly irrelevant. No new enterprise systems
> will be written in VFP and existing ones will gradually be
> re-written in dotNet. I'll continue to use VFP for non mission-critical
> apps with a lifespan of around 5 years or less and for prototyping.
> But seriously, how can you justify application development in VFP
> to your customers when MS has publicly stated that there will be
> no more development of the product beyond SP2?
>
> -Roger
You may be right with many new apps. But, it's no easy task to just rewrite
an existing app in a completely different language. I think for custom apps
as well as vertical market apps, the end user doesn't care what language it
is written in so long as it works.
Mike
Paul Lee
write caching?
-----------------------------------------------------------------
Paul Lee ........... Abri Technologies ......... http://abri.com/
'Recover' - top rated FoxPro file repair utility.
-----------------------------------------------------------------
"MikeA" <app...@appellsoftware.com> wrote in
news:GO0hi.2720$YS.2580@trnddc03:
Roger Ansell
"MikeA" <app...@appellsoftware.com> wrote:
[snip]
>> Aye but we'll be increasingly irrelevant. No new enterprise systems
>> will be written in VFP and existing ones will gradually be
>> re-written in dotNet. I'll continue to use VFP for non
>> mission-critical
>> apps with a lifespan of around 5 years or less and for prototyping.
>> But seriously, how can you justify application development in VFP
>> to your customers when MS has publicly stated that there will be
>> no more development of the product beyond SP2?
> You may be right with many new apps. But, it's no easy task to just
> rewrite an existing app in a completely different language. \
Mike, I completely agree. But that's exactly what's happening here in
South Oz in the public (ie government) sector and from what I've
gathered from scanning the contract positions for VFP developers
in Oz, most of them relate to assisting in re-writing VFP apps in
dotNet & MS SQL Server.
> I think for custom apps as well as vertical market apps ...
... they're definitely my markets ...
> ... the end user doesn't care what language it is written in so long
> as it works.
Generally, that's correct. But if and when VFP stops working
in the next MS OS (and there are no workarounds as there
are in Vista), what then?
-Roger
MikeA
caching. Some of my client's computer consultants go against my advice only
to have a random power surge on their server one afternoon and lose the
entire day's work. The client of mine with this problem is in the process
of upgrading their server. I'm fairly confident that it is the Win 98
server with XP workstations causing the conflict.
Thanks,
Mike
"Paul Lee" <n...@spam.please> wrote in message
news:Xns9960E20...@207.46.248.16...