NasibKalsi
Programmer
Hi All:
Is there any function to find out if the dbf is open in Shared or Exclusive mode ?
My Best
Is there any function to find out if the dbf is open in Shared or Exclusive mode ?
My Best
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Dbf is open in Shared or Exclusive mode 3
- Thread starter NasibKalsi
- Start date
- Status
Mike Gagnon
Programmer
Take a look at TRY AND CATCH in the help file.
Try to open the table in shared mode:
Mike Gagnon
If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)
Try to open the table in shared mode:
Code:
USE myTable excl in 0 again
TRY
USE myTable shared again in 0
CATCH to loError
messagebox("Table is already opened in exclusive mode")
ENDTRYMike Gagnon
If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)
-
1
- #3
Mike - "messagebox("Table is already opened in exclusive mode")" Not necessarily.
Just because I cannot open it in EXCLUSIVE, doesn't necessarily mean that someone else has it in EXCLUSIVE mode. They may have it in SHARED mode, and it would still prevent me from opening it EXCLUSIVE.
NasibKalsi - Mike's suggestion above would work well to determine if YOU could open a data table (DBF file) in EXCLUSIVE mode. If you can't open it in EXCLUSIVE mode then someone else has it in use (either EXCLUSIVE or SHARED).
If you are questioning the status of how YOU have opened the table, that is based on 2 things.
1. SET EXCLUSIVE ON/OFF
If your application is running with SET EXCLUSIVE ON, then every table you open will be in EXCLUSIVE mode unless you specifically use the SHARED option.
Use ?SET('EXCLUSIVE') to check your own VFP environment setting.
2. How you USE your own tables
If you USE Mytable IN 0 ALIAS Whatever EXCLUSIVE you will obviously have it open in EXCLUSIVE mode.
Good Luck,
JRB-Bldr
Just because I cannot open it in EXCLUSIVE, doesn't necessarily mean that someone else has it in EXCLUSIVE mode. They may have it in SHARED mode, and it would still prevent me from opening it EXCLUSIVE.
NasibKalsi - Mike's suggestion above would work well to determine if YOU could open a data table (DBF file) in EXCLUSIVE mode. If you can't open it in EXCLUSIVE mode then someone else has it in use (either EXCLUSIVE or SHARED).
If you are questioning the status of how YOU have opened the table, that is based on 2 things.
1. SET EXCLUSIVE ON/OFF
If your application is running with SET EXCLUSIVE ON, then every table you open will be in EXCLUSIVE mode unless you specifically use the SHARED option.
Use ?SET('EXCLUSIVE') to check your own VFP environment setting.
2. How you USE your own tables
If you USE Mytable IN 0 ALIAS Whatever EXCLUSIVE you will obviously have it open in EXCLUSIVE mode.
Good Luck,
JRB-Bldr
- Thread starter
- #5
NasibKalsi
Programmer
Thank you all.
Cetin: I could not find the function isexclusive() in vfp 9.2
However, I found another function isflock() that return the status, if the file opened is for exclusive use.
JRB-Bldr - You are right. Thanks for your explanation.
Cetin: I could not find the function isexclusive() in vfp 9.2
However, I found another function isflock() that return the status, if the file opened is for exclusive use.
JRB-Bldr - You are right. Thanks for your explanation.
-
1
- #6
Mike Lewis
Programmer
Nasib,
Cetin is right. You need ISEXLUSIVE(). ISFLOCK() won't do what you want.
ISEXCLUSIVE() determines if a table that is already open is open in exclusive or shared mode. (I don't know why you say you can't find it. It's definitely present in VFP 9.0.)
ISFLOCK() merely checks the file lock status. It's quite possible for a table to be locked but still open in shared mode.
JRB-Bldr is also correct. If you try to open a table exclusively, and if the attempt fails, then all it tells you is that the table is already open. It doesn't say whether it was your program or another one that opened it; nor does it say whether it was opened exclusively or shared.
Perhaps you could tell us why you need to know the table-opening mode - or what you are trying to achieve.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro tips, advice, training, consultancy
Custom software for your business
Cetin is right. You need ISEXLUSIVE(). ISFLOCK() won't do what you want.
ISEXCLUSIVE() determines if a table that is already open is open in exclusive or shared mode. (I don't know why you say you can't find it. It's definitely present in VFP 9.0.)
ISFLOCK() merely checks the file lock status. It's quite possible for a table to be locked but still open in shared mode.
JRB-Bldr is also correct. If you try to open a table exclusively, and if the attempt fails, then all it tells you is that the table is already open. It doesn't say whether it was your program or another one that opened it; nor does it say whether it was opened exclusively or shared.
Perhaps you could tell us why you need to know the table-opening mode - or what you are trying to achieve.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro tips, advice, training, consultancy
Custom software for your business
You can find the documentation about IsExclusive() here:
There is a little quirk in VFP, that if a table is opened by you in shared mode, then opening it EXCLUSIVE again in another workarea succeeds silently but opens the table in shared mode. For this reason, if you need it for something that needs exclusive access then the only reliable method is to use the IsExclusive().
Cetin Basoz
MS Foxpro MVP, MCP
There is a little quirk in VFP, that if a table is opened by you in shared mode, then opening it EXCLUSIVE again in another workarea succeeds silently but opens the table in shared mode. For this reason, if you need it for something that needs exclusive access then the only reliable method is to use the IsExclusive().
Cetin Basoz
MS Foxpro MVP, MCP
-
1
- #8
NasibKalsi ,
There have been issues with the VFP 9 help file. You may need to update yours.
-Dave Summers-
![[cheers]](/data/assets/smilies/cheers.gif "[cheers] [cheers]")
Even more Fox stuff at:
There have been issues with the VFP 9 help file. You may need to update yours.
-Dave Summers-
Even more Fox stuff at:
- Thread starter
- #9
NasibKalsi
Programmer
Dave: Thanks a lot for the help file, I just updated my vfp 9.2. You have saved me a lot of time, it may be trivial but big for me, you deserve above 8.
Mike: I love reading your posts, it is like a story with lots of VFP in it. yes, after downloading the help file from Dave, help ISEXCLISIVE works. I should have tried without looking at the help file.
Reason for using Exclusive: 1. I have a small application where I open the table for read only, except when I need to updates. I need to compact the table with blob fields, with a size of 1GB or so. I just want to make sure that I can open the file for exclusive use. I was not ready to read my old code. So try to find a quick fix. Long story short, I fixed the code the way it is supposed to be. 2. For debug purposes, I made a small class which will report the status of the open tables, including index keys, relations, filters, etc.
Cetin : Thanks a lot.
Mike: I love reading your posts, it is like a story with lots of VFP in it. yes, after downloading the help file from Dave, help ISEXCLISIVE works. I should have tried without looking at the help file.
Reason for using Exclusive: 1. I have a small application where I open the table for read only, except when I need to updates. I need to compact the table with blob fields, with a size of 1GB or so. I just want to make sure that I can open the file for exclusive use. I was not ready to read my old code. So try to find a quick fix. Long story short, I fixed the code the way it is supposed to be. 2. For debug purposes, I made a small class which will report the status of the open tables, including index keys, relations, filters, etc.
Cetin : Thanks a lot.
"I just want to make sure that I can open the file for exclusive use."
Unfortunately the ISEXCLUSIVE() command will not do what you want.
It will only tell you if the file is open on your workstation in EXCLUSIVE mode. It will not tell you if someone else has the table open.
You are better off to try to open it EXCLUSIVE and then TRAP on an error (should one occur). Then if you get the error - test the error number.
If it should be
1705 File access denied
then you know that someone else has the file in use and you cannot open it EXCLUSIVE.
Good Luck,
JRB-Bldr
Unfortunately the ISEXCLUSIVE() command will not do what you want.
It will only tell you if the file is open on your workstation in EXCLUSIVE mode. It will not tell you if someone else has the table open.
You are better off to try to open it EXCLUSIVE and then TRAP on an error (should one occur). Then if you get the error - test the error number.
If it should be
1705 File access denied
then you know that someone else has the file in use and you cannot open it EXCLUSIVE.
Good Luck,
JRB-Bldr
While searching this forum for the error code 1705 I found another approach.
You might want to look at:
How to know if a table is used by another user
thread184-925399
Or:
Checking for Table usage
thread184-969013
There are good suggestions in both, but I especially liked Olaf's suggestion in the last one.
It doesn't involve having to use Error numbers at all.
Good Luck,
JRB-Bldr
You might want to look at:
How to know if a table is used by another user
thread184-925399
Or:
Checking for Table usage
thread184-969013
There are good suggestions in both, but I especially liked Olaf's suggestion in the last one.
It doesn't involve having to use Error numbers at all.
Good Luck,
JRB-Bldr
Mike Lewis
Programmer
Nasib,
Glad to hear my post was useful. Thanks for the star.
Just to add a word to JRB-Bldr's comment:
The best that ISEXCLUSIVE() can do is to tell you about the current status of a table. It won't tell you whether you'll be able to open the table in in the future.
The only way you can guarantee to be able to open a table (exclusively or otherwise) it to actually try to open it. With any other approach, there will always be a time lag between testing the status and opening it. You can't be sure that the status won't change in that period.
OK, I know it's extremely unlikely, but it's always possible that someone will open or close the table in the tiny interval between your determinng the status and actually opening the table yourself.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro tips, advice, training, consultancy
Custom software for your business
Glad to hear my post was useful. Thanks for the star.
Just to add a word to JRB-Bldr's comment:
The best that ISEXCLUSIVE() can do is to tell you about the current status of a table. It won't tell you whether you'll be able to open the table in in the future.
The only way you can guarantee to be able to open a table (exclusively or otherwise) it to actually try to open it. With any other approach, there will always be a time lag between testing the status and opening it. You can't be sure that the status won't change in that period.
OK, I know it's extremely unlikely, but it's always possible that someone will open or close the table in the tiny interval between your determinng the status and actually opening the table yourself.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro tips, advice, training, consultancy
Custom software for your business
Olaf Doschke
Programmer
Hello jrbbldr,
thanks for liking my FLOCK() suggestion. Especially as it would also work in the case Cetin mentions here, if VFP opens a table shared, even if you make a USE table EXCLUSIVE and already have open the table shared in another workarea (and another alias).
The only disadvantage is the little time interval from unlocking the FLOCK and actually opening the table exclusive.
Checking with ISEXCLUSIVE() seems a good idea anyway as the last step before PACKing or doing anything else.
In fact if you talk about a single user desktop app here it's a good idea to work with SET EXCLUSIVE ON, because not only while writing or doing operations on tables that require exclusive use, but also on 'normal' shared write operations this makes it faster for VFP, as it does not need automatic locking then. That's only applicable to local data and/or a single user application, but can speed up the performance a bit.
Bye, Olaf.
thanks for liking my FLOCK() suggestion. Especially as it would also work in the case Cetin mentions here, if VFP opens a table shared, even if you make a USE table EXCLUSIVE and already have open the table shared in another workarea (and another alias).
The only disadvantage is the little time interval from unlocking the FLOCK and actually opening the table exclusive.
Checking with ISEXCLUSIVE() seems a good idea anyway as the last step before PACKing or doing anything else.
In fact if you talk about a single user desktop app here it's a good idea to work with SET EXCLUSIVE ON, because not only while writing or doing operations on tables that require exclusive use, but also on 'normal' shared write operations this makes it faster for VFP, as it does not need automatic locking then. That's only applicable to local data and/or a single user application, but can speed up the performance a bit.
Bye, Olaf.
- Status
Similar threads
- Locked
- Question
