>>>>From the documentation:
>>>>
>>>>"Issue SET RESOURCE TO without a resource file name to open the default Foxuser.dbf resource file. Issuing SET RESOURCE TO performs an implicit SET RESOURCE ON."
>>>
>>>George, thank you for reply.
>>>
>>>Look carefully to the last two lines:
>>>
>>>SET RESOURCE TO
>>>
>>>sets the resource to some foxuser file.
>>>
>>>In this case, previous resource file (ressurss.dbf) table must be released and can be used by USE command or by any other application.
>>>
>>>However last line
>>>
>>>USE RESSURSS causes error. This means that when RESSURSS.DBF is
>>>used as resource file,
>>>
>>>SET RESOURCE TO
>>>
>>>COMMAND DOES NOT RELEASE RESSURSS.DBF file.
>>>
>>>This is related to the ressurss.fpt file structure. This
>>>fpt file confuces VFP 7 so that it does not release it after SET RESOURCE TO
>>>command.
>>>
>>>THIS IS BUG !
>>
>>First, I do not appreciate your shouting at me and, therefore, may be a little more blunt and a little less tactful than usual.
>>
>>In order for this to be a bug it must be replicatable with any valid resource file
>>
>>It is not! I've tested the following over and over and have not been able to replicate it. My normal resource file is differently named than the default. The code below which I've used to do these tests has not once demonstrated the behavior you describe.

lcresource = SET("Resource" , 1)
>>* lcresource equals C:\FOX\VFPUSER.DBF
>>USE (lcresource) AGAIN IN 0 ALIAS myresource
>>USE
>>SET RESOURCE TO
>>* The following prints C:\WINNT\SYSTEM32\FOXUSER.DBF
>>? SET("Resource" , 1)
>>USE C:\FOX\VFPUSER.DBF
>>USE
>>SET RESOURCE TO (lcresource)

I have done this both with and without using the resource file again.
>>
>>It is to no one's advantage to start yelling "BUG!" without being able to categorically prove and replicate it. In fact, it does a disservice to the community as a whole. The mere fact that it cannot be replicated with any valid resource file dis-proves your statement.
>>
>>SET BUG OFF
>
>George, to to the following typical situation:
>
>1. I have a config.fpw file with
>
>resource=RESSURSS
>
>line included.
>
>2. This config.fpw file is included in vfp 7 application .exe file.
>
>3. VFP application crashes with one of the C5 errors reported previosuly and
>resource memo file gets corrupted.
>
>4. In next run, vfp asks:
>The resource file is not valid.
>Overwrite it with a new empty one ?
>
>5. You may answer to Yes or No, no matter.
>It will continue to ask so for every run.
>
>Isn't this a bug ?
>
>6. It does not allow to repair the corrupted resource file.
>
>James Sounders wrote:
>
>Apparently, the file gets partially opened in the system datasession
>when doing the SET RESOURCE, and does not get closed until you exit and
>restart VFP.
>
>So it is IMPOSSIBLE even to fix resource file corruption in my code if
>config.fpw file with resource file setting is included inside .exe file.
>
>I receive a lot of support calls about this issue.
>
>If this is not a bug, is it behaviour by desing ?
>
>To fix this, I must open a resource file manually at my exe startup and
>issue a pack or some other command to dedect memo file corruption and to fix it.
>
>Do you really think that this is the good way ?

Andrus,

First, please allow me to apologize for my tone in my previous post. It's clear to me now that you didn't mean to shout.

Second, being unaware of the exact circumstances of what was occurring, I was unable to fully analyze the circumstances. So you have my apology for that as well.

Now whether or not it's a bug is another question completely. It could be that the OS is not releasing the file handle properly when the SET RESOUCE TO command is issue. Last night I was able to demonstrate that under Win98SE. Also, if the application resides on a Novell network, that OS is notorious for being slow in this process.

Now to see if we can find a workaround for the problem.

My question would be, "Is there any reason why the resource file is included with the executable?"

To me, this is sort of like asking for a problem. I know that there are instances where people supply resource files in order to control things like the Print Preview toolbar. Including it with the setup, but excluding it from the exe would solve the problem.

I would think, however, because you've included it in the exe, that you have a need to do so. In that light, I'd make the following suggestion.

1. Include the resource file in the executable and either change its name or the name in the config.fpw file.

2. On startup, SET RESOURCE OFF, open the dbf indicated in the config.fpw file and append into it from the included dbf, then reset with SET RESOURCE TO < filename > You could then delete it on shutdown, if necessary.

Another suggestion might be to programmatically create the resource file.

This of any help?