stupid errors

In this multi-user (usually no more than a dozen or so) file server app, I
sometimes get errors that seem to make no sense. For instance, a line like
this got a "file in use" error:

INSERT INTO mytable VALUES (1, 2, "abcd")

Nowhere in the app is mytable locked or opened exclusively. There are no
FoxPro users who might have opened the table in FoxPro, and there are no
other processes that access the tables.

This particular process has been operating for more than a year without
error, now this. I occasionally - maybe once every month or two - get
unexpected errors like this in other procs. Anyone have an idea what's going
on?

Could network issues be causing this?

Most data access in this app uses views or sometimes tables directly, but
buffered. But there are a few cases, like this one, where data contention is
so unexpected that I didn't bother buffering and just access the table
directly. For crying out loud, how can a simple INSERT fail, if nothing is
locking the table? (There might be an occasional APPEND, but it would be
short, no more than a handful of records.)

REPROCESS is set to 0.

Why is this happening? Do I have to start buffering everything?

Rolf
Thu Mar 24 17:50:12 CST 2005

> Could network issues be causing this?


http://support.microsoft.com/?kbid=296264
http://support.microsoft.com/?kbid=299603
http://support.microsoft.com/default.aspx/kb/294816/EN-US/
http://support.microsoft.com/kb/818528

Jan
Thu Mar 24 18:39:35 CST 2005

Paul,

What OSes and what hardware?

Rgds
Jan

"Paul Pedersen" <no-reply@swen.com> wrote in message
news:%23Jv2irLMFHA.4092@tk2msftngp13.phx.gbl...
> In this multi-user (usually no more than a dozen or so) file server app, I
> sometimes get errors that seem to make no sense. For instance, a line like
> this got a "file in use" error:
>
> INSERT INTO mytable VALUES (1, 2, "abcd")
>
> Nowhere in the app is mytable locked or opened exclusively. There are no
> FoxPro users who might have opened the table in FoxPro, and there are no
> other processes that access the tables.
>
> This particular process has been operating for more than a year without
> error, now this. I occasionally - maybe once every month or two - get
> unexpected errors like this in other procs. Anyone have an idea what's
> going on?
>
> Could network issues be causing this?
>
> Most data access in this app uses views or sometimes tables directly, but
> buffered. But there are a few cases, like this one, where data contention
> is so unexpected that I didn't bother buffering and just access the table
> directly. For crying out loud, how can a simple INSERT fail, if nothing is
> locking the table? (There might be an occasional APPEND, but it would be
> short, no more than a handful of records.)
>
> REPROCESS is set to 0.
>
> Why is this happening? Do I have to start buffering everything?
>
>
>

Paul
Thu Mar 24 18:42:37 CST 2005

Thanks. I'm not sure I understand the first one. I'll keep reading it. It
seems to refer only to "server message block" clients, and I don't know what
that means.

The other three, I've already seen, but they refer to Terminal Services,
which I'm not using.



"Rolf Lystad" <rolf@invalid.invalid> wrote in message
news:OaRE6wMMFHA.1476@TK2MSFTNGP09.phx.gbl...
>> Could network issues be causing this?
>
>
> http://support.microsoft.com/?kbid=296264
> http://support.microsoft.com/?kbid=299603
> http://support.microsoft.com/default.aspx/kb/294816/EN-US/
> http://support.microsoft.com/kb/818528
>
>
>
>
>

Paul
Thu Mar 24 19:07:00 CST 2005

Most are WinXP Pro, but there could be a Win2k or two in there. I think all
are P4's, but again there could be a P3 somewhere. The file server is WinXP
Pro, P4, not a terribly fast one, but enough RAM and lots of disk space. It
keeps a little busy, but I don't think it gets a very heavy load overall.

I don't know about the network hardware.




"Jan" <Nomail@Nowhere.com> wrote in message
news:OSTiQMNMFHA.2648@TK2MSFTNGP14.phx.gbl...
> Paul,
>
> What OSes and what hardware?
>
> Rgds
> Jan
>
> "Paul Pedersen" <no-reply@swen.com> wrote in message
> news:%23Jv2irLMFHA.4092@tk2msftngp13.phx.gbl...
>> In this multi-user (usually no more than a dozen or so) file server app,
>> I sometimes get errors that seem to make no sense. For instance, a line
>> like this got a "file in use" error:
>>
>> INSERT INTO mytable VALUES (1, 2, "abcd")
>>
>> Nowhere in the app is mytable locked or opened exclusively. There are no
>> FoxPro users who might have opened the table in FoxPro, and there are no
>> other processes that access the tables.
>>
>> This particular process has been operating for more than a year without
>> error, now this. I occasionally - maybe once every month or two - get
>> unexpected errors like this in other procs. Anyone have an idea what's
>> going on?
>>
>> Could network issues be causing this?
>>
>> Most data access in this app uses views or sometimes tables directly, but
>> buffered. But there are a few cases, like this one, where data contention
>> is so unexpected that I didn't bother buffering and just access the table
>> directly. For crying out loud, how can a simple INSERT fail, if nothing
>> is locking the table? (There might be an occasional APPEND, but it would
>> be short, no more than a handful of records.)
>>
>> REPROCESS is set to 0.
>>
>> Why is this happening? Do I have to start buffering everything?
>>
>>
>>
>
>

Jan
Fri Mar 25 02:51:53 CST 2005

Paul,

I would echo Rolf's response. XP with SP2 exasperated to opportunistic
locking problem. Here are two files that turn it off. Run both on all win2K
& XP machines.

Cut and paste the following into a file called woplocks.reg


REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkStation\Parameters]
"EnableOplockForceClose"=dword:00000001
"EnableOplocks"=dword:00000000
"UseOpportunisticLocking"=dword:00000000


Cut and paste the following into a file called soplocks.reg

REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters]
"EnableOplockForceClose"=dword:00000001
"EnableOplocks"=dword:00000000

Rgds
Jan B

"Paul Pedersen" <no-reply@swen.com> wrote in message
news:O1yl1bNMFHA.244@TK2MSFTNGP12.phx.gbl...
> Most are WinXP Pro, but there could be a Win2k or two in there. I think
> all are P4's, but again there could be a P3 somewhere. The file server is
> WinXP Pro, P4, not a terribly fast one, but enough RAM and lots of disk
> space. It keeps a little busy, but I don't think it gets a very heavy load
> overall.
>
> I don't know about the network hardware.
>
>
>
>
> "Jan" <Nomail@Nowhere.com> wrote in message
> news:OSTiQMNMFHA.2648@TK2MSFTNGP14.phx.gbl...
>> Paul,
>>
>> What OSes and what hardware?
>>
>> Rgds
>> Jan
>>
>> "Paul Pedersen" <no-reply@swen.com> wrote in message
>> news:%23Jv2irLMFHA.4092@tk2msftngp13.phx.gbl...
>>> In this multi-user (usually no more than a dozen or so) file server app,
>>> I sometimes get errors that seem to make no sense. For instance, a line
>>> like this got a "file in use" error:
>>>
>>> INSERT INTO mytable VALUES (1, 2, "abcd")
>>>
>>> Nowhere in the app is mytable locked or opened exclusively. There are no
>>> FoxPro users who might have opened the table in FoxPro, and there are no
>>> other processes that access the tables.
>>>
>>> This particular process has been operating for more than a year without
>>> error, now this. I occasionally - maybe once every month or two - get
>>> unexpected errors like this in other procs. Anyone have an idea what's
>>> going on?
>>>
>>> Could network issues be causing this?
>>>
>>> Most data access in this app uses views or sometimes tables directly,
>>> but buffered. But there are a few cases, like this one, where data
>>> contention is so unexpected that I didn't bother buffering and just
>>> access the table directly. For crying out loud, how can a simple INSERT
>>> fail, if nothing is locking the table? (There might be an occasional
>>> APPEND, but it would be short, no more than a handful of records.)
>>>
>>> REPROCESS is set to 0.
>>>
>>> Why is this happening? Do I have to start buffering everything?
>>>
>>>
>>>
>>
>>
>
>

Leemi
Fri Mar 25 09:08:19 CST 2005

Hi Paul:

Along with all the other suggestions you received, make sure you prevent
any anti virus from scanning you VFP data file. See this article:

http://support.microsoft.com/default.aspx?scid=KB;EN-US;321550

Also, you might want to add a SET TABLEVALIDATE TO 4 or to 0 to your code.
You can sometimes gets an error like you mention when VFP locks the header
records to check it and then someone else tries to access the table. (I
assume you are using VFP 8.0 or later. )

I hope this helps.

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

Sincerely,
Microsoft FoxPro Technical Support
Lee Mitchell

*-- VFP9 HAS ARRIVED!! --*
Read about all the new features of VFP9 here:
http://msdn.microsoft.com/vfoxpro/

*--Purchase VFP 9.0 here:
http://www.microsoft.com/PRODUCTS/info/product.aspx?view=22&pcid=54787e64-52
69-4500-8bf2-3f06689f4ab3&type=ovr

Keep an eye on the product lifecycle for Visual FoxPro here:
http://support.microsoft.com/default.aspx?id=fh;[ln];lifeprodv
- VFP5 Mainstream Support retired June 30th, 2003
- VFP6 Mainstream Support retired Sept. 30th, 2003


> In this multi-user (usually no more than a dozen or so) file server app,
I
> sometimes get errors that seem to make no sense. For instance, a line
like
> this got a "file in use" error:
>
> INSERT INTO mytable VALUES (1, 2, "abcd")
>
> Nowhere in the app is mytable locked or opened exclusively. There are no
> FoxPro users who might have opened the table in FoxPro, and there are no
> other processes that access the tables.
>
> This particular process has been operating for more than a year without
> error, now this. I occasionally - maybe once every month or two - get
> unexpected errors like this in other procs. Anyone have an idea what's
> going on?
>
> Could network issues be causing this?
>
> Most data access in this app uses views or sometimes tables directly, but
> buffered. But there are a few cases, like this one, where data contention
> is so unexpected that I didn't bother buffering and just access the table
> directly. For crying out loud, how can a simple INSERT fail, if nothing
is
> locking the table? (There might be an occasional APPEND, but it would be
> short, no more than a handful of records.)
>
> REPROCESS is set to 0.
>
> Why is this happening? Do I have to start buffering everything?

John
Fri Mar 25 09:29:07 CST 2005

Hey Paul,

What sort of reprocess settings do you have? Commands that add records
implicitly lock the table (or its header, at least) so VFP-locking could
still be an issue. Though from the amount of load you describe, I would
imagine your retry setting (look at SET REPROCESS) would have to be fairly
tight to see this happening.

HTH,

John

"Paul Pedersen" <no-reply@swen.com> wrote in message
news:%23Jv2irLMFHA.4092@tk2msftngp13.phx.gbl...
> In this multi-user (usually no more than a dozen or so) file server app, I
> sometimes get errors that seem to make no sense. For instance, a line like
> this got a "file in use" error:
>
> INSERT INTO mytable VALUES (1, 2, "abcd")
>
> Nowhere in the app is mytable locked or opened exclusively. There are no
> FoxPro users who might have opened the table in FoxPro, and there are no
> other processes that access the tables.
>
> This particular process has been operating for more than a year without
> error, now this. I occasionally - maybe once every month or two - get
> unexpected errors like this in other procs. Anyone have an idea what's
> going on?
>
> Could network issues be causing this?
>
> Most data access in this app uses views or sometimes tables directly, but
> buffered. But there are a few cases, like this one, where data contention
> is so unexpected that I didn't bother buffering and just access the table
> directly. For crying out loud, how can a simple INSERT fail, if nothing is
> locking the table? (There might be an occasional APPEND, but it would be
> short, no more than a handful of records.)
>
> REPROCESS is set to 0.
>
> Why is this happening? Do I have to start buffering everything?
>
>
>

Paul
Fri Mar 25 14:33:04 CST 2005

Thanks. I'll read that article again and check out your solution.


"Jan" <nomail@nowhere.com> wrote in message
news:eNjQBfRMFHA.2464@TK2MSFTNGP10.phx.gbl...
> Paul,
>
> I would echo Rolf's response. XP with SP2 exasperated to opportunistic
> locking problem. Here are two files that turn it off. Run both on all
> win2K & XP machines.
>
> Cut and paste the following into a file called woplocks.reg
>
>
> REGEDIT4
>
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkStation\Parameters]
> "EnableOplockForceClose"=dword:00000001
> "EnableOplocks"=dword:00000000
> "UseOpportunisticLocking"=dword:00000000
>
>
> Cut and paste the following into a file called soplocks.reg
>
> REGEDIT4
>
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters]
> "EnableOplockForceClose"=dword:00000001
> "EnableOplocks"=dword:00000000
>
> Rgds
> Jan B
>
> "Paul Pedersen" <no-reply@swen.com> wrote in message
> news:O1yl1bNMFHA.244@TK2MSFTNGP12.phx.gbl...
>> Most are WinXP Pro, but there could be a Win2k or two in there. I think
>> all are P4's, but again there could be a P3 somewhere. The file server is
>> WinXP Pro, P4, not a terribly fast one, but enough RAM and lots of disk
>> space. It keeps a little busy, but I don't think it gets a very heavy
>> load overall.
>>
>> I don't know about the network hardware.
>>
>>
>>
>>
>> "Jan" <Nomail@Nowhere.com> wrote in message
>> news:OSTiQMNMFHA.2648@TK2MSFTNGP14.phx.gbl...
>>> Paul,
>>>
>>> What OSes and what hardware?
>>>
>>> Rgds
>>> Jan
>>>
>>> "Paul Pedersen" <no-reply@swen.com> wrote in message
>>> news:%23Jv2irLMFHA.4092@tk2msftngp13.phx.gbl...
>>>> In this multi-user (usually no more than a dozen or so) file server
>>>> app, I sometimes get errors that seem to make no sense. For instance, a
>>>> line like this got a "file in use" error:
>>>>
>>>> INSERT INTO mytable VALUES (1, 2, "abcd")
>>>>
>>>> Nowhere in the app is mytable locked or opened exclusively. There are
>>>> no FoxPro users who might have opened the table in FoxPro, and there
>>>> are no other processes that access the tables.
>>>>
>>>> This particular process has been operating for more than a year without
>>>> error, now this. I occasionally - maybe once every month or two - get
>>>> unexpected errors like this in other procs. Anyone have an idea what's
>>>> going on?
>>>>
>>>> Could network issues be causing this?
>>>>
>>>> Most data access in this app uses views or sometimes tables directly,
>>>> but buffered. But there are a few cases, like this one, where data
>>>> contention is so unexpected that I didn't bother buffering and just
>>>> access the table directly. For crying out loud, how can a simple INSERT
>>>> fail, if nothing is locking the table? (There might be an occasional
>>>> APPEND, but it would be short, no more than a handful of records.)
>>>>
>>>> REPROCESS is set to 0.
>>>>
>>>> Why is this happening? Do I have to start buffering everything?
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Paul
Fri Mar 25 14:34:38 CST 2005

REPROCESS is set to 0, meaning it's supposed to sit and wait forever for
access. That shouldn't be a problem, since I've tried to make all writes as
quick as possible.



"John Spiegel" <jspiegel@NOSPAMc-comld.com> wrote in message
news:%23L$kr6UMFHA.3076@TK2MSFTNGP14.phx.gbl...
> Hey Paul,
>
> What sort of reprocess settings do you have? Commands that add records
> implicitly lock the table (or its header, at least) so VFP-locking could
> still be an issue. Though from the amount of load you describe, I would
> imagine your retry setting (look at SET REPROCESS) would have to be fairly
> tight to see this happening.
>
> HTH,
>
> John
>
> "Paul Pedersen" <no-reply@swen.com> wrote in message
> news:%23Jv2irLMFHA.4092@tk2msftngp13.phx.gbl...
>> In this multi-user (usually no more than a dozen or so) file server app,
>> I sometimes get errors that seem to make no sense. For instance, a line
>> like this got a "file in use" error:
>>
>> INSERT INTO mytable VALUES (1, 2, "abcd")
>>
>> Nowhere in the app is mytable locked or opened exclusively. There are no
>> FoxPro users who might have opened the table in FoxPro, and there are no
>> other processes that access the tables.
>>
>> This particular process has been operating for more than a year without
>> error, now this. I occasionally - maybe once every month or two - get
>> unexpected errors like this in other procs. Anyone have an idea what's
>> going on?
>>
>> Could network issues be causing this?
>>
>> Most data access in this app uses views or sometimes tables directly, but
>> buffered. But there are a few cases, like this one, where data contention
>> is so unexpected that I didn't bother buffering and just access the table
>> directly. For crying out loud, how can a simple INSERT fail, if nothing
>> is locking the table? (There might be an occasional APPEND, but it would
>> be short, no more than a handful of records.)
>>
>> REPROCESS is set to 0.
>>
>> Why is this happening? Do I have to start buffering everything?
>>
>>
>>
>
>

Paul
Fri Mar 25 14:51:14 CST 2005

Thank you.

I don't think a virus scanner is causing the problem, because it's so rare,
only every few weeks. Anyway, I'm not sure these computers even have
antivirus on them.

But the TABLEVALIDATE might do it. This is written in VFP8, so there doesn't
seem to be an option 4. Setting it to 0 sounds like it would speed up
operation, but what is the downside? Minor corruption could be converted
into a major hosing, maybe. Any other thoughts?

Also, with REPROCESS set to 0 as it is, I would expect that this problem
would not occur. Comments?



"Lee Mitchell" <Leemi@online.microsoft.com> wrote in message
news:bztJ8xUMFHA.1016@TK2MSFTNGXA03.phx.gbl...
> Hi Paul:
>
> Along with all the other suggestions you received, make sure you prevent
> any anti virus from scanning you VFP data file. See this article:
>
> http://support.microsoft.com/default.aspx?scid=KB;EN-US;321550
>
> Also, you might want to add a SET TABLEVALIDATE TO 4 or to 0 to your code.
> You can sometimes gets an error like you mention when VFP locks the header
> records to check it and then someone else tries to access the table. (I
> assume you are using VFP 8.0 or later. )
>
> I hope this helps.
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> Sincerely,
> Microsoft FoxPro Technical Support
> Lee Mitchell
>
> *-- VFP9 HAS ARRIVED!! --*
> Read about all the new features of VFP9 here:
> http://msdn.microsoft.com/vfoxpro/
>
> *--Purchase VFP 9.0 here:
> http://www.microsoft.com/PRODUCTS/info/product.aspx?view=22&pcid=54787e64-52
> 69-4500-8bf2-3f06689f4ab3&type=ovr
>
> Keep an eye on the product lifecycle for Visual FoxPro here:
> http://support.microsoft.com/default.aspx?id=fh;[ln];lifeprodv
> - VFP5 Mainstream Support retired June 30th, 2003
> - VFP6 Mainstream Support retired Sept. 30th, 2003
>
>
>> In this multi-user (usually no more than a dozen or so) file server app,
> I
>> sometimes get errors that seem to make no sense. For instance, a line
> like
>> this got a "file in use" error:
>>
>> INSERT INTO mytable VALUES (1, 2, "abcd")
>>
>> Nowhere in the app is mytable locked or opened exclusively. There are no
>> FoxPro users who might have opened the table in FoxPro, and there are no
>> other processes that access the tables.
>>
>> This particular process has been operating for more than a year without
>> error, now this. I occasionally - maybe once every month or two - get
>> unexpected errors like this in other procs. Anyone have an idea what's
>> going on?
>>
>> Could network issues be causing this?
>>
>> Most data access in this app uses views or sometimes tables directly, but
>> buffered. But there are a few cases, like this one, where data contention
>> is so unexpected that I didn't bother buffering and just access the table
>> directly. For crying out loud, how can a simple INSERT fail, if nothing
> is
>> locking the table? (There might be an occasional APPEND, but it would be
>> short, no more than a handful of records.)
>>
>> REPROCESS is set to 0.
>>
>> Why is this happening? Do I have to start buffering everything?
>
>

Leemi
Fri Mar 25 16:25:31 CST 2005

Hi Paul:

The 4 option was added in VFP 8.0 SP1, so you need to install SP1 to get
this. Using 4 normally prevents these problems and is safer than setting it
to 0. You can use 0 if you are unlikely to exceed the 2 GB limit of the
file.

The SET REPROCESS and the TABLEVALIDATE are two separate things. You can
still see problems with TABLEVALIDATE regardless of the REPORCESS setting.

I hope this helps.

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

Sincerely,
Microsoft FoxPro Technical Support
Lee Mitchell

*-- VFP9 HAS ARRIVED!! --*
Read about all the new features of VFP9 here:
http://msdn.microsoft.com/vfoxpro/

*--Purchase VFP 9.0 here:
http://www.microsoft.com/PRODUCTS/info/product.aspx?view=22&pcid=54787e64-52
69-4500-8bf2-3f06689f4ab3&type=ovr

Keep an eye on the product lifecycle for Visual FoxPro here:
http://support.microsoft.com/default.aspx?id=fh;[ln];lifeprodv
- VFP5 Mainstream Support retired June 30th, 2003
- VFP6 Mainstream Support retired Sept. 30th, 2003

>Thank you.

>I don't think a virus scanner is causing the problem, because it's so
rare,
>only every few weeks. Anyway, I'm not sure these computers even have
>antivirus on them.

>But the TABLEVALIDATE might do it. This is written in VFP8, so there
doesn't
>seem to be an option 4. Setting it to 0 sounds like it would speed up
>operation, but what is the downside? Minor corruption could be converted
>into a major hosing, maybe. Any other thoughts?

>Also, with REPROCESS set to 0 as it is, I would expect that this problem
>would not occur. Comments?


"Lee Mitchell" <Leemi@online.microsoft.com> wrote in message
news:bztJ8xUMFHA.1016@TK2MSFTNGXA03.phx.gbl...
> Hi Paul:
>
> Along with all the other suggestions you received, make sure you prevent
> any anti virus from scanning you VFP data file. See this article:
>
> http://support.microsoft.com/default.aspx?scid=KB;EN-US;321550
>
> Also, you might want to add a SET TABLEVALIDATE TO 4 or to 0 to your code.
> You can sometimes gets an error like you mention when VFP locks the header
> records to check it and then someone else tries to access the table. (I
> assume you are using VFP 8.0 or later. )
>
> I hope this helps.
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> Sincerely,
> Microsoft FoxPro Technical Support
> Lee Mitchell
>
> *-- VFP9 HAS ARRIVED!! --*
> Read about all the new features of VFP9 here:
> http://msdn.microsoft.com/vfoxpro/
>
> *--Purchase VFP 9.0 here:
>
http://www.microsoft.com/PRODUCTS/info/product.aspx?view=22&pcid=54787e64-52
> 69-4500-8bf2-3f06689f4ab3&type=ovr
>
> Keep an eye on the product lifecycle for Visual FoxPro here:
> http://support.microsoft.com/default.aspx?id=fh;[ln];lifeprodv
> - VFP5 Mainstream Support retired June 30th, 2003
> - VFP6 Mainstream Support retired Sept. 30th, 2003
>
>
>> In this multi-user (usually no more than a dozen or so) file server app,
> I
>> sometimes get errors that seem to make no sense. For instance, a line
> like
>> this got a "file in use" error:
>>
>> INSERT INTO mytable VALUES (1, 2, "abcd")
>>
>> Nowhere in the app is mytable locked or opened exclusively. There are no
>> FoxPro users who might have opened the table in FoxPro, and there are no
>> other processes that access the tables.
>>
>> This particular process has been operating for more than a year without
>> error, now this. I occasionally - maybe once every month or two - get
>> unexpected errors like this in other procs. Anyone have an idea what's
>> going on?
>>
>> Could network issues be causing this?
>>
>> Most data access in this app uses views or sometimes tables directly, but
>> buffered. But there are a few cases, like this one, where data contention
>> is so unexpected that I didn't bother buffering and just access the table
>> directly. For crying out loud, how can a simple INSERT fail, if nothing
> is
>> locking the table? (There might be an occasional APPEND, but it would be
>> short, no more than a handful of records.)
>>
>> REPROCESS is set to 0.
>>
>> Why is this happening? Do I have to start buffering everything?

Paul
Fri Mar 25 17:43:39 CST 2005


> The 4 option was added in VFP 8.0 SP1, so you need to install SP1 to get
> this. Using 4 normally prevents these problems and is safer than setting
> it
> to 0. You can use 0 if you are unlikely to exceed the 2 GB limit of the
> file.

Thanks for the info. I have SP1, and tried the setting. It works. (Well,
didn't get an error, anyway.) But it's not documented in the help file. Is
there an updated Help available? I don't see it on the VFP update page.



> The SET REPROCESS and the TABLEVALIDATE are two separate things. You can
> still see problems with TABLEVALIDATE regardless of the REPORCESS setting.

So the lock performed during the table validation on open is not a "normal"
lock?

Jake
Sat Mar 26 08:48:49 CST 2005

I am getting these same errors on a VFP 7 application that has been
running on Terminal Services for several years. I usually see the
error when the user is first logging onto the application and access's
a user table to get their rights. This is a read-only table, but see
the error occasionally and can't figure out why. This just started
happening about 2 months ago. I have seen this happen with just 1
user using the application. I know that BackUpExec is doing something
around this time, but not sure what. I know its Not backing up files.
Very frustrating...

On Fri, 25 Mar 2005 12:34:38 -0800, "Paul Pedersen"
<no-reply@swen.com> wrote:

>REPROCESS is set to 0, meaning it's supposed to sit and wait forever for
>access. That shouldn't be a problem, since I've tried to make all writes as
>quick as possible.
>
>
>
>"John Spiegel" <jspiegel@NOSPAMc-comld.com> wrote in message
>news:%23L$kr6UMFHA.3076@TK2MSFTNGP14.phx.gbl...
>> Hey Paul,
>>
>> What sort of reprocess settings do you have? Commands that add records
>> implicitly lock the table (or its header, at least) so VFP-locking could
>> still be an issue. Though from the amount of load you describe, I would
>> imagine your retry setting (look at SET REPROCESS) would have to be fairly
>> tight to see this happening.
>>
>> HTH,
>>
>> John
>>
>> "Paul Pedersen" <no-reply@swen.com> wrote in message
>> news:%23Jv2irLMFHA.4092@tk2msftngp13.phx.gbl...
>>> In this multi-user (usually no more than a dozen or so) file server app,
>>> I sometimes get errors that seem to make no sense. For instance, a line
>>> like this got a "file in use" error:
>>>
>>> INSERT INTO mytable VALUES (1, 2, "abcd")
>>>
>>> Nowhere in the app is mytable locked or opened exclusively. There are no
>>> FoxPro users who might have opened the table in FoxPro, and there are no
>>> other processes that access the tables.
>>>
>>> This particular process has been operating for more than a year without
>>> error, now this. I occasionally - maybe once every month or two - get
>>> unexpected errors like this in other procs. Anyone have an idea what's
>>> going on?
>>>
>>> Could network issues be causing this?
>>>
>>> Most data access in this app uses views or sometimes tables directly, but
>>> buffered. But there are a few cases, like this one, where data contention
>>> is so unexpected that I didn't bother buffering and just access the table
>>> directly. For crying out loud, how can a simple INSERT fail, if nothing
>>> is locking the table? (There might be an occasional APPEND, but it would
>>> be short, no more than a handful of records.)
>>>
>>> REPROCESS is set to 0.
>>>
>>> Why is this happening? Do I have to start buffering everything?
>>>
>>>
>>>
>>
>>
>

David
Mon Mar 28 10:34:46 CST 2005

Paul,

You can think of the contention as an issue of how long it takes the disk to
write the row into the table, if a disk cluster allocation is involved it'll
make it even longer.

If none of the other answers solve it, you can trap on this error, issue a
short delay the Sleep() API call works well and then RETRY.

--
df - Microsoft MVP FoxPro http://www.geocities.com/df_foxpro

"Paul Pedersen" <no-reply@swen.com> wrote in message
news:%23Jv2irLMFHA.4092@tk2msftngp13.phx.gbl...
> In this multi-user (usually no more than a dozen or so) file server app, I
> sometimes get errors that seem to make no sense. For instance, a line like
> this got a "file in use" error:
>
> INSERT INTO mytable VALUES (1, 2, "abcd")
>
> Nowhere in the app is mytable locked or opened exclusively. There are no
> FoxPro users who might have opened the table in FoxPro, and there are no
> other processes that access the tables.
>
> This particular process has been operating for more than a year without
> error, now this. I occasionally - maybe once every month or two - get
> unexpected errors like this in other procs. Anyone have an idea what's
> going on?
>
> Could network issues be causing this?
>
> Most data access in this app uses views or sometimes tables directly, but
> buffered. But there are a few cases, like this one, where data contention
> is so unexpected that I didn't bother buffering and just access the table
> directly. For crying out loud, how can a simple INSERT fail, if nothing is
> locking the table? (There might be an occasional APPEND, but it would be
> short, no more than a handful of records.)
>
> REPROCESS is set to 0.
>
> Why is this happening? Do I have to start buffering everything?
>
>
>