Discussion:
Foxuser.dbf file cause application crash
(too old to reply)
Andrea Mariottini
2003-08-05 12:47:26 UTC
Permalink
I have this this problem on Win2000 only systems:
my application crashes very early at startup, I found it
doesn't crash if I:
- flag foxuser.* files as read-only
- delete foxuser.* files (but in this way it crashes next startup)

This never happened in the past and I can't find a reason.
At startup I SET RESOURCE OFF.
I changed nothing in my startup procedure.
--
Andrea Mariottini
Andrea Mariottini
2003-08-05 13:51:22 UTC
Permalink
Try a "config.fpw" file with a line
resource = off
Otherwise the Fox runtime would create a "foxuser.dbf" at
startup automatically before the first line of your own code
actually runs.
I can't use a config.fpw file because a bug I found: if I include
a fpw file in my exe then I have problems with
createobject("VisualFoxPro.Application").

If I could find the cause of this, maybe I can solve in another way...
I don't explain why this never happened before, and why only on Win2000.
--
Andrea Mariottini
Lee Mitchell
2003-08-05 14:28:00 UTC
Permalink
Hi Andrea:

Have you tried disabling any anti virus software that is running on the
machine? If you are running Norton AV, you can prevent it from scanning
VFP data files. See:

321550 HOWTO: Optimize Visual FoxPro Applications While Using Norton
AntiVirus
http://support.microsoft.com/?id=321550

What version of VFP are you using? Are your run time files the same
version as the development version used to compile your executable?

I hope this helps.

This posting is provided "AS IS" with no warranties, and confers no rights.

Sincerely,
Microsoft FoxPro Technical Support
Lee Mitchell

*-- VFP8 HAS ARRIVED!! --*
Read about all the new features of VFP8 here:
http://www.universalthread.com/VisualFoxPro/News/VFP8Release.asp
Purchase VFP8 here:
http://shop.microsoft.com/Referral/Productinfo.asp?siteID=11518

Keep an eye on the product lifecycle for Visual FoxPro here:
http://support.microsoft.com/default.aspx?id=fh;[ln];lifeprodv
- VFP5 Mainstream Support retires June 30th, 2003
- VFP6 Mainstream Support retires Sept. 30th, 2003
Try a "config.fpw" file with a line
resource = off
Otherwise the Fox runtime would create a "foxuser.dbf" at
startup automatically before the first line of your own code
actually runs.
I can't use a config.fpw file because a bug I found: if I include
a fpw file in my exe then I have problems with
createobject("VisualFoxPro.Application").
If I could find the cause of this, maybe I can solve in another way...
I don't explain why this never happened before, and why only on Win2000.
--
Andrea Mariottini
Andrea Mariottini
2003-08-06 08:46:36 UTC
Permalink
Post by Lee Mitchell
Have you tried disabling any anti virus software that is running on the
machine? If you are running Norton AV, you can prevent it from scanning
Tried but not working.
Post by Lee Mitchell
What version of VFP are you using? Are your run time files the same
version as the development version used to compile your executable?
VFP5 with latest Visual Studio SP (SP3 if I remember..)
Same version as development.
--
Andrea Mariottini
Dan Freeman
2003-08-05 16:18:16 UTC
Permalink
Whoa! Back up! Your situation has anomaly written all over it. :-)

1. Why are you creating an instance of VisualFoxpro.Application in a runtime
app? Technically speaking, that object shouldn't be available *anyway* and
at runtime you can get a reference to the application object through _VFP.

2. What problems were you encountering? I have serious doubts that it had
anything at all to do with including a config.fpw.

3. What version of VFP?

Dan
Post by Andrea Mariottini
Try a "config.fpw" file with a line
resource = off
Otherwise the Fox runtime would create a "foxuser.dbf" at
startup automatically before the first line of your own code
actually runs.
I can't use a config.fpw file because a bug I found: if I include
a fpw file in my exe then I have problems with
createobject("VisualFoxPro.Application").
If I could find the cause of this, maybe I can solve in another way...
I don't explain why this never happened before, and why only on Win2000.
--
Andrea Mariottini
Leonid
2003-08-06 11:13:45 UTC
Permalink
May be

set resource off
delete file foxuser.dbf
delete file foxuser.fpt

will help you?

Leonid
Then put the following line at the beginning of your main
set resource off
This is what I already do very early at startup!!
1. Why are you creating an instance of VisualFoxpro.Application in a runtime
app? Technically speaking, that object shouldn't be available *anyway* and
at runtime you can get a reference to the application object through _VFP.
I use VFP5 and I create an instance of VisualFoxpro.Application from
VBA (Word). I know this doesn't work with VFP6/7/8 but works with VFP5
and now I can't change my application logic at the moment.
2. What problems were you encountering? I have serious doubts that it had
anything at all to do with including a config.fpw.
If I include a config.fpw file, then createobject fails. I tested it and if
I remove the config.fpw then it works. I have no doubts on this.
Now the mail problem is why the foxuser.dbf/fpt files cause application
to crash. As I said this happens only on Win2000 systems (and not all...
On my test machines this doesn't happen).
This never occurred before and I made no changes in my startup code.
The crash occurs very early at startup and I suspect before any code
is executed (my code obviously, not VFP internal..)
--
Andrea Mariottini
Fred Taylor
2003-08-06 15:20:30 UTC
Permalink
If you're using VFP5, you can't share the FOXUSER files anyways.
--
Fred
Microsoft Visual FoxPro MVP
Please respond only to the newsgroups so that all may benefit.
Post by Leonid
May be
set resource off
delete file foxuser.dbf
delete file foxuser.fpt
will help you?
I'll try it as soon as possible, but because the problem
doesn't occurs on machines I have access to, I'll need to distribute
a new exe to my customers having problem.
A note: my app is shared over the network so I think I can't
delete those file without access violation.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.506 / Virus Database: 303 - Release Date: 8/1/2003
Andrea Mariottini
2003-08-07 13:19:02 UTC
Permalink
Thanks to all for the solutions proposed.
By now I think to flag the file as read-only is the better choice
because I don't have to change my code.
However I would like to understand "why" this strange behavior
(never seen before) on Win2000 systems (not all!).
I hope someone in Microsoft could reply.
--
Andrea Mariottini
Lee Mitchell
2003-08-05 13:51:07 UTC
Permalink
Hi Andrea:

Do you need the foxuser file for anything? If not, place a RESOURCE=OFF in
the Config.fpw file. This prevents VFP from creating the Foxuser files in
the first place.

If you delete the Foxuser.* files and they are corrupted on the next start
up, there must be something on the machine that is conflicting with VFP
writing to this file. Does the machine have any anti virus software
running? If so, can you disable this software, delete the Foxuser.* files,
and restart? Does the corruption occur? If you are running Norton anti
virus, you can prevent this software from scanning VFP data files. See

321550 HOWTO: Optimize Visual FoxPro Applications While Using Norton
AntiVirus
http://support.microsoft.com/?id=321550

I hope this helps.

This posting is provided "AS IS" with no warranties, and confers no rights.

Sincerely,
Microsoft FoxPro Technical Support
Lee Mitchell

*-- VFP8 HAS ARRIVED!! --*
Read about all the new features of VFP8 here:
http://www.universalthread.com/VisualFoxPro/News/VFP8Release.asp
Purchase VFP8 here:
http://shop.microsoft.com/Referral/Productinfo.asp?siteID=11518

Keep an eye on the product lifecycle for Visual FoxPro here:
http://support.microsoft.com/default.aspx?id=fh;[ln];lifeprodv
- VFP5 Mainstream Support retires June 30th, 2003
- VFP6 Mainstream Support retires Sept. 30th, 2003
Post by Andrea Mariottini
my application crashes very early at startup, I found it
- flag foxuser.* files as read-only
- delete foxuser.* files (but in this way it crashes next startup)
This never happened in the past and I can't find a reason.
At startup I SET RESOURCE OFF.
I changed nothing in my startup procedure.
--
Andrea Mariottini
Loading...