Programming with dBASE - ROW IN USE BY ANOTHER

Author

ROW IN USE BY ANOTHER

Dennis Levy

2005-11-29, 8:23 pm

When we are using our program multiple user with 2 or more users, when we go into our SALES screen or PURCHASE ORDER screen, we always get the error: ROW IN USE BY ANOTHER. RETRYING LOCK. The bde is correctly set for multi-user. I know that the grid in ea
ch of these two programs is set to EDIT, is that an issue. If we can't do this, it would make it hard on the user to do immediate updates. What are the things that can cause this error message. The system is supposed to be multi-user and we should not get
this error.
Dennis and Maxine

Christopher F. Neumann

2005-11-29, 8:23 pm

If both are in edit mode, are they on the same row also?

--

Christopher F. Neumann

[dBASE Gold Charter Member 107]
Blue Star Visual dBASE graduate
IWA-HWG Web Technologies Certified
IWA-HWG Web Programming Certified
ICCP TCP/IP Network Analyst
Data Communications Engineer
http://cfneumann.us

"Just hanging out on the Sagittarian arm of the Milky Way"

Dennis Levy wrote:
> When we are using our program multiple user with 2 or more users,
> when we go into our SALES screen or PURCHASE ORDER screen, we always
> get the error: ROW IN USE BY ANOTHER. RETRYING LOCK. The bde is
> correctly set for multi-user. I know that the grid in each of these
> two programs is set to EDIT, is that an issue. If we can't do this,
> it would make it hard on the user to do immediate updates. What are
> the things that can cause this error message. The system is supposed
> to be multi-user and we should not get this error. Dennis and Maxine

Les Shewchuk

2005-11-29, 8:23 pm

"Dennis Levy" <Lcibiz@pacbell.net> wrote in message
news:hu6Jf1R9FHA.1520@news-server...
> When we are using our program multiple user with 2 or more users, when we
> go into our SALES screen or PURCHASE ORDER screen, we always get the
> error: ROW IN USE BY ANOTHER. RETRYING LOCK. The bde is correctly set for
> multi-user. I know that the grid in each of these two programs is set to
> EDIT, is that an issue. If we can't do this, it would make it hard on the
> user to do immediate updates. What are the things that can cause this
> error message. The system is supposed to be multi-user and we should not
> get this error.
> Dennis and Maxine

I've hit this one a couple of times. Let me guess. (SPO = Sales or Purchase
Order)

You screens have a Parent/Child of SPO headings to Detail Lines.
You have a menu or button that opens the appropriate SPO form.
That form Opens on the first available SPO heading
The form then allows you to navigate to the SPO you actually want to edit.
User1 opens the form and is on the 1st record.
User2 gets the error...unless User1 has moved to another record before User2
opens the form.
BUT User2 gets the error when they try to navigate past the SPO that User1
is editing.

Try this; In the form on_open the SPO form, call an unlock() on the SPO
heading rowset. This doesn't always work. (depends on the complexity of the
SPO form) but is the simplest thing to try.

OR

Create a "zero" record in your SPO headers that you open the form on,
immediately navigate away from and then never let the user navigate back to.

User 1 opens the form on record zero and instantly jumps to record 1.
User 2 opens the form on record zero, tries to jump to record 1, receives
and error and moves on to record 2.
If User 1 then tries to move to record 2, would get the error and move on to
record 3.

OR (and this is a little more complicated)

Take the navigation OUT of the SPO form.
* Make a dialogue box that opens the SPO heading file only with the
requestlive set to false.
* From the dialogue, create the SPO form (use the "set procedure; f = new
SalesFORM();" etc. do not use "do Sales.wfm")
* From the dialogue, move the SPO's rowset to the requested record and try
to lock it.
* If the lock fails (in use by another) display an error, destroy the SPO
form and ask the user to select another heading.

* To navigate from the SPO form, call the open dialogue form again and close
the SPO form

I know, it's not detailed, but it's a place to start.

Les Shewchuk

Bob Buchanan

2005-11-30, 8:23 pm

Hello Dennis and Maxine:

My thoughts are to wonder if any of the tables you are using in the Sales
and PO screens may be still active somewhere else in your system. If any
table you are using in either module is active anywhere else in the system,
that fun message will appear. When that message crops up in my app, I embed
an, ? INSPECT(_app), command in the ONOPEN of the culprit module -- in your
case the Sales and/or PO modules. Going in, that should help you run down
which table may still be active. Be sure to run through all the logic legs
of your system prior to entering either culprit screen to make sure you are
using the one that is causing the problem.

In my home module, I have developed a "kill all objects that are not needed"
module. This way, when any station returns to that screen, I know that they
have no open modules that might effect other users.

====
Not with this BDE <g>. Wouldn't it be nice if the error displayed where the
other occurrence was still active?

Regards, Bob

RLB & Associates
(916) 761-8737
www.rvspacemanager.com

"Dennis Levy" <Lcibiz@pacbell.net> wrote in message
news:hu6Jf1R9FHA.1520@news-server...[color=darkred]
> When we are using our program multiple user with 2 or more users, when we
> go into our SALES screen or PURCHASE ORDER screen, we always get the
> error: ROW IN USE BY ANOTHER. RETRYING LOCK. The bde is correctly set for
> multi-user. I know that the grid in each of these two programs is set to
> EDIT, is that an issue. If we can't do this, it would make it hard on the
> user to do immediate updates. What are the things that can cause this
> error message. The system is supposed to be multi-user and we should not
> get this error.
> Dennis and Maxine

Sponsored Links