Use exclusive Workaround

Hi All
Dbase allows you to use the command
use mytable exclusive 
/* if the table was open exclusive you get an error message and you cannot
continue.
BUT   if the table was opened elsewhere first  but without being EXCLUSIVE you
get no error message.

I found out that Dbase tests the table, and knows it is open elsewhere but not
exclusive but just opens it without being exclusive AND in the IDE tells you. so
any command that requires excluive use now generates an error.
to test for this in the the command window paste the code below
close databases
 // then verify that your test table is not open EXCLUSIVE elsewhere or you will
get an error message. 
select 1
use mytable exclusive
/* Look at the status line at the bottom right of your screen
  it should displays 3 things mytable.dbf  exclusive and 1/plus the # of records
in the  table
*/
* now enter this
close databases
* status bar is now empty so enter
use mytable
* the status bar now displays only 2 things mytable.dbf  and 1/plus the # *of
records in the  table
* now enter
select 2
use mytabler exclusive
/* you receive no error message but the bottom right displays :
   Not what it displayed the first time, but the same blank middle space!
      mytable.dbf               and 1/# of records in the  table
    it   DOES NOT display "exclusive" in the middle

I do not if the three displays are form.fields, displaying variables or rows of
an array or just a single line of text.
   
 So my question is this:
Can anyone tell us where the display is stored?
It would then be simple to code a routine like:
*/ 
do while .t.
   use mytable exclusive
   if  isblank(form.stored.value) //or maybe 
   if at(upper(EXCLUSIVE"),form.stored.value)>0
      do something... pack,reindex zap what ever
   else
       if msgbox("Mytable.dbf is opened
elsewhere."+chr(13)+"Enter Yes after closing it to retry, or no to
cancel this process","Open file Error",36)<>6
         exit
    endif
enddo
use

Thanks
John Jay
charter member 502

In article <M71OJqNnIHA.320@news-server>, best_nospam_mar@sbcglobal.net 
says...
> Hi All
> Dbase allows you to use the command
> use mytable exclusive 
> /* if the table was open exclusive you get an error message and you cannot
continue.
> BUT   if the table was opened elsewhere first  but without being EXCLUSIVE
you get no error message.
> 
> I found out that Dbase tests the table, and knows it is open elsewhere but
not exclusive but just opens it without being exclusive AND in the IDE tells
you. so any command that requires excluive use now generates an error.
> to test for this in the the command window paste the code below
> close databases
>  // then verify that your test table is not open EXCLUSIVE elsewhere or you
will get an error message. 
> select 1
> use mytable exclusive
> /* Look at the status line at the bottom right of your screen
>   it should displays 3 things mytable.dbf  exclusive and 1/plus the # of
records in the  table
> */
> * now enter this
> close databases
> * status bar is now empty so enter
> use mytable
> * the status bar now displays only 2 things mytable.dbf  and 1/plus the #
*of records in the  table
> * now enter
> select 2
> use mytabler exclusive
> /* you receive no error message but the bottom right displays :
>    Not what it displayed the first time, but the same blank middle space!
>       mytable.dbf               and 1/# of records in the  table
>     it   DOES NOT display "exclusive" in the middle
> 
> I do not if the three displays are form.fields, displaying variables or
rows of an array or just a single line of text.
>    
>  So my question is this:
> Can anyone tell us where the display is stored?
> It would then be simple to code a routine like:
> */ 
> do while .t.
>    use mytable exclusive
>    if  isblank(form.stored.value) //or maybe 
>    if at(upper(EXCLUSIVE"),form.stored.value)>0
>       do something... pack,reindex zap what ever
>    else
>        if msgbox("Mytable.dbf is opened
elsewhere."+chr(13)+"Enter Yes after closing it to retry, or no to
cancel this process","Open file Error",36)<>6
>          exit
>     endif
> enddo
> use
> 
> Thanks
> John Jay
> charter member 502
 

John,

Checkout the useExclusive.prg in the dUFLP. It is available at Ken 
Mayer's site:

http://www.goldenstag.net/dbase/

-- 
Geoff Wass [dBVIPS]
Montréal, Québec, Canada

.|.|.|        dBASE info at http://geocities.com/geoff_wass       |.|.|.
.|.|.| ---------------------------------------------------------- |.|.|.

Hi Jeff,
  Checkout the useExclusive.prg in the dUFLP. It is available at Ken 
> Mayer's site:

   I am familiar with this workaround using 
    delete tag DummyXYZ // nonexistant index tag
 But I believe you should not be able to use a Dbase command that only works
correctly under one set of circumstances and consistently generates an error in
another.
imho a workaround is not needed, but a completion of the command is.
I do not think of this is a bug either.
   I have discussed this with someone at Dbase who promised to pass this idea
along to the proper people but I have not heard back so I would like to come up
with the solution and use it (possibly as a cc) then pass it along to Dbase for
inclusion in a future update when it fits into their schedule
  The other side of this is will it work in runtime? Gary White found that in
runtime the speed of some long processes are greatly improved by setting talk
off. The is removes display to the command window and status bar so this idea/
fix  shouldwork in runtime also. 

John Jay
Charter Member 502

In article <AN24JYlnIHA.1516@news-server>, BestONSPAMnar@sbcglobal.net 
says...
> Hi Jeff,
>   Checkout the useExclusive.prg in the dUFLP. It is available at Ken 
> > Mayer's site:
> 
>    I am familiar with this workaround using 
>     delete tag DummyXYZ // nonexistant index tag
>  But I believe you should not be able to use a Dbase command that only
works correctly under one set of circumstances and consistently generates an
error in another.
> imho a workaround is not needed, but a completion of the command is.
> I do not think of this is a bug either.
>    I have discussed this with someone at Dbase who promised to pass this
idea along to the proper people but I have not heard back so I would like to
come up with the solution and use it (possibly as a cc) then pass it along to 
Dbase for inclusion in a future update when it fits into their schedule
>   The other side of this is will it work in runtime? Gary White found that
in runtime the speed of some long processes are greatly improved by setting talk
off. The is removes display to the command window and status bar so this 
idea/ fix  shouldwork in runtime also. 
> 
> John Jay
> Charter Member 502


John,

It has worked this way, consistently, since the release of the 32-bit 
version of dBASE (VdB 7.0) in 1998.

Tables are not needed "exclusive" that often. PACKing is only needed 
once in a while and can be done before the desktop application starts or 
after hours in a network environment. Often the same applies to ZAPping. 
If you are needing to do either frequently, either a rethink of the 
application design or a switch to a database backend like Firebird is in 
order. Relational database products like Firebird, MS SQL Server, 
Oracle, etc. perform hard deletes, so they do not need packing the way 
dBASE tables do.

Beyond that, all I can suggest is you post a wish in the dbase.wishlist 
news group.

-- 
Geoff Wass [dBVIPS]
Montréal, Québec, Canada

.|.|.|        dBASE info at http://geocities.com/geoff_wass       |.|.|.
.|.|.| ---------------------------------------------------------- |.|.|.

Hi Geoff, 
 > It has worked this way, consistently, since the release of the 32-bit 
> version of dBASE (VdB 7.0) in 1998.

  You have been using the product a long time and I have been using it since
Dbase III. We are well versed on some of it’s quirks and take them into account
and (hopefully) remember where to go for help or workarounds. This particular
instance is not a learning curve new users should have to go through. Imho it is
not unreasonable to say 10 years of doing something one way when there is an
easier way should be long enough.
    I looked at the new “Features and Fixes” in the latest release 2.6.1.4 and
it lists 11 changes to the combo box control and I do not need any of them,
others do I guess. Are they more important to a database management software
program than to be able to open a table correctly every time? I do not expect
the development team to stop their work and fix this, but given the evidence
that it is solved but not implemented it should be worth a few minutes of some
ones time.
If openexclusive(my.form.mytable) // or something like it
   Do something
else
     Msgbox(error message here)
endif
Working consistently would be worth US $100.00 to me 
 The 11 combox events including BeforeDropDown are of no value to me. 

PACKing is only needed once in a while and can be done before the desktop
application starts or after hours in a network environment. Often the same
applies to ZAPping. 

   My invoicing app  uses pack EVERY day. And if I did not need it in another
spot I would not bring it up. Soft deletes have saved me from unfixable data
loss more often than I care to admit so changing to another platform would cause
the loss of a great feature.

If you are needing to do either frequently, rethink the application design.

I must respectfully disagree with this statement. Here is how I interpret this.
John there is a known undocumented problem with the command use <some
table> exclusive,
In some uses it works correctly, in some others it does not. We know exactly
when it causes the user an error but rather than dbase fixing it is the
responsibility of all users to stumble across it, and design a code fix for it.

   As a programmer my code works in my tests but other users use it differently.
I MUST fix any code error this basic that I wrote and I expect no less of Dbase.
And in the effort to help I have asked the newsgroup users for help to point
Dbase in a direction that might be a quick fix.
 
> Beyond that, all I can suggest is you post a wish in the dbase.wishlist 
> news group.

I am venting, not bitching. I am one of Dbase’s most loyal users but it seems
odd to me to say Dbase “I wish I could open tables correctly every time”.
That said I hope someone can say how to test the
"ExclusiveField.value" will so I could point Dbase in that direction
in a wishlist post.
Thanks John