Record locking

[Doug]

Has anybody ever encountered the error "Record is in use by another user"
when you're the only one in the system? The record in question was obviously
locked by myself since I'm the only one in the system yet I get this error
like there's somebody else on the system who locked the record I'm trying to
write to. And if I'm the person who locked this record than why can't I
write to a record I locked myself? I thought if you lock a record then you
can do whatever you want with it as far as reading and writing but other
users can't.

Where am I going wrong and why can't I write to a record that I locked?

Please help. This is driving me crazy!

Thanks.

Doug

[Olaf Doschke]

Are you doing this from two seperate VFP processes? Then you are locking
yourself indeed. Another reason may be, you're using the same table in two
different workareas or even in two different datasessions. A lock really is
a per filehandle lock, not a per user account lock and as such you can lock
yourself out, even in the same process.

Bye, Olaf.

[Doug]

Thanks for your response. This is what I'm doing.

I have a form with a combo box with the rowsource property set to a sql
statement:

SELECT * FROM importer INTO CURSOR invImporter ORDER BY ImporterName WHER
!notcurrentimporter AND !importerarchived

Then I call another form from this form which has an edit box on it. I had
the controlsource property of the edit box set to
'invImporter.importerinvoicenotes'. This is what I had last night when I
posted this message. After I posted it I figured that the problem was using
the field name from a sql file into the controlsource of another field.

Then I tried creating a new sql statement in the second form that's exactly
like the other sql except creating a different cursor name. This actually
worked which I can use but I'm now looking for a simpler solution.

What I tried next was to set the Value property of the second form's edit
box with invImporter.importerinvoicenotes but I get the "Attempting to lock
..." message again. I don't know why this doesn't work. Any ideas?

Doug

"Olaf Doschke" <b2xhZi5kb3NjaGt...@strconv.14.de> wrote in
message news:eupvJBL...@TK2MSFTNGP04.phx.gbl...

[Olaf Doschke]

> I have a form with a combo box with the rowsource property set to a sql
> statement:
>
> SELECT * FROM importer INTO CURSOR invImporter ORDER BY ImporterName WHER
> !notcurrentimporter AND !importerarchived

An SQL does create a readonly cursor if not specified otherwise.
That maybe one root of your problem.

> What I tried next was to set the Value property of the second form's edit
> box with invImporter.importerinvoicenotes but I get the "Attempting to
> lock ..." message again. I don't know why this doesn't work. Any ideas?

If the Editbox isn't set Readonly and has a controlsource set setting focus
to
it will try writing to the controlsource.

Setting the value should work, as soon as you unset the Editboxs
controlsource,
because then the only thing you'll edit is the Editbox.Value but not any
field of any controlsource.

AS you don't specify what the controlsource of the other forms editbox is,
this might be the thing to look at, but I'd search for even another third
source of the "attempting to lock" message. A lock attempt is made at
writing, not at reading.

Bye, Olaf.

[Doug]

Thanks again. I did have the editbox's controlsource set which was my
problem. I didn't fully understand that the cursor created by the sql
statement wouldn't work with a control source. I think I understand where I
went wrong now. I decided to forget about touching the sql statement and use
the original table and just a value property in the edit box, not a control
source. It's working now so I appreciate all your advice.

Doug

"Olaf Doschke" <b2xhZi5kb3NjaGt...@strconv.14.de> wrote in

message news:%23FSwV6W...@TK2MSFTNGP06.phx.gbl...