Hi!

I don't know. I just tried to create new database, close VFP, set on the read-only flag for all 3 files of database. Then use OPEN DATA ... SHARED command over that database and it is opened ok.

Try following:
VALIDATE DATABASE
- if not help, look for views I have mentioned that contain '*' in their query and change the order of result fields to force it to query fields list instead of '*'.
- if not help, try to re-create database using GENDBC utility - generate the PRG file using database, re-create its structure, then copy data. Here GENDBC can fail at some moment if problem is in the database structure.

Again, I'm not sure if all above help, and it could take some time.

Indeed it is strange for me - what can cause VFP to update database file just during the OPEN DATABASE command???

Try also to ask this question again here, but in another manner (What can cause update of the database just during the OPEN DATA ... SHARED command? and describe the trick with trying to set read-only flag for DBC files).

HTH.

>Hello again,
>
>I tried setting the .dbc file to read-only, and I tried setting all 3 db files, the .dbc, the .dct, & the .dcx files to read-only. Each time, as soon as they tried to log in and the command OPEN DATA db/sys SHARED command was executed, we received an error message that the .dct file was missing or invalid. I tried taking off the SHARED part of the OPEN command and just ensure that EXCLUSIVE was set to OFF. It still gave us the error message. Should a simple OPEN DATA command get messed up because the .dbc file is read-only? Is this a sign of some large problem?
>
>Thanks Vlad.
>
>>Hi!
>>
>>Its strange. Kick out all users, make DBC and related files read-only on the system level, then try to run app again. You will spot this way all points in app that cuase changes in the database. I'm still sute the reason is some code that cause database changes. Try also the most simple - validate database command.
>>
>>Also, if you have view like 'SELECT * from ...', that * can cause re-reading of all fields structure from the table and trying of updating of the database files (I'm not sure in this, just a thought). So, avout using views like 'select *'. In the view designer you can quickly get rid of '*' just by changing the order of fields in view.
>>
>>HTH.
>>
>>>Vlad,
>>>
>>>We don't do any modifications to database objects on the fly. One of the more common locations we get this error has the following:
>>>
>>>LOCAL lcName, lcParamName, lcViewName
>>>lcParamName = 'vp' + pcType + 'ID'
>>>lcViewName = 'sys!' + pcType + '_ExactOnView'
>>>&lcParamName = pcID
>>>USE (lcViewName) IN 0 ALIAS cTemp000 Shared
>>>
>>>We create the viewname on the fly. But the view already exists. No changes are made to it. The last line with the USE in it is the one where they get the ERROR READING FILE. Then once in awhile, it leaves everything locked up. Other users don't get any error message, they just freeze. If we find the person that has the lock on the .dbc file and knock them off, everyone else resumes execution.
>>>
>>>Thanks.
>>>
>>>>Hi!
>>>>
>>>>What is the exact command that cause the error? Do you modify the database or database objects structure on the fly in the application? Any word on after what moment database is locked by another user?
>>>>
>>>>>We currently use VFP 6.0 as a front end running Sql Server 7.0 on the back end. We do most of the interaction with the database using remote views. We have been getting quite a few ERROR READING FILE (1104) errors throughout the day. No single spot in the application errors every time. It can happen at different locations in the application. The users who get the error also seem random. One of the most common locations where we get the error is using a view that only pulls 1 record. The view that is used shares a connection. I believe that all views that share that connection have the ShareConnection property set to True.
>>>>>
>>>>>The properties of this view include the following: ShareConnection = True, FetchSize = -1, MaxRecords = -1, FetchAsNeeded = False.
>>>>>
>>>>>An addition problem: We may see 10 to 15 of these ERROR READING FILE errors, but maybe once to 3 times per day, the error leaves the user with a lock on the DBC file, locking all of the other users out. Each time we have to get into WinFile and find the user with a lock on the DBC file and knock them out, while every user we have is stuck. This does not help our company's efficiency.
>>>>>
>>>>>Microsoft has been no help. Does anybody have any ideas what I might be missing?