Jürgen,
You are cordially invited to adjust the code with a try...catch. Would you wind when you have updated that procedure to upload it here? I can than also refresh my basic library. Thanks , Koen
Op di 23 jul. 2019 om 15:31 schreef juergen@wondzinski.de:
Hi Koen,
now that's a very old coding style. Probably from the time before TRY/CATCH was invented.
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von Koen Piller Gesendet: Dienstag, 23. Juli 2019 20:32 An: ProFox Email List profox@leafe.com Betreff: Re: vfp9 exe
Hi, you can make use of Craig Boyd's procedure, you shall have to parse your DBC for every file to find if anything in use and than you can make a message to the other users to please quit the application. But, but, but. Why do you need to reindex? That should be a flaw in your design. Please study again the nessessity and try to redesign. If in any doubt of why/how, advise you to post a new topic. Meanwhile, Craoig's coding:
**Procedure by Craig Boyd **See also Tektips: https://www.tek-tips.com/viewthread.cfm?qid=925399 ?IsTableInUse( https://www.tek-tips.com/viewthread.cfm?qid=925399?IsTableInUse( "C:\mytable.dbf")
FUNCTION IsTableInUse(tcTableName) SET ASSERTS ON ASSERT PCOUNT() > 0 MESSAGE "Developer Error: Table name parameter is required!" ASSERT TYPE("tcTableName") = "C" MESSAGE "Developer Error: Table name parameter must be a character!" ASSERT !EMPTY(tcTableName) MESSAGE "Developer Error: Table name parameter is empty!" ASSERT FILE(tcTableName) MESSAGE "Developer Error: Table does not exist!"
LOCAL lcErrorHandlerWas, llReturn lcErrorHandlerWas = ON("ERROR") ON ERROR llReturn = .T. && Could call proc that checks for ERROR() = 3"File is in use" USE (tcTableName) IN 0 EXCLUSIVE USE IN SELECT(JUSTSTEM(tcTableName)) ON ERROR &lcErrorHandlerWas RETURN llReturn ENDFUNC
Regards,
Koen
Op di 23 jul. 2019 om 12:58 schreef Kurt @ Gmail kurthwendt@gmail.com:
Why not create a single file - with a single record, a File Lock Flag. So - when a user goes to reindex files - they MUST Lock that one record 1st. Then, at the startup of your system - for regular users - the system must check that flag & record to see if someone locked it and is indexing files.
It's a thought...
-K-
On 7/23/2019 10:36 AM, Ken McGinnis wrote:
We have a vfp9 SP2 program that has been running nearly bug free for over 10 years. Only now we have a need to find out if anyone else is using the exe in a specific folder. We allow many users to have their own unique folder with their patient data files.
So we log into folder 1 and another user is in folder 2. No problem.
If we log into folder 1 and another user is in that same folder, again no problem. Our software is multi-user down to the individual record level. The problem is when the 2nd user comes in and needs to lock many or all files to reindex or other procedures. How can the 2nd user know that another user is there? Again it is not a problem until that 1st user starts to do something, almost anything that requires accessing files. All files are locked by the 2nd user so the 1st user starts getting errors.
We could try to lock the exe and that would fail so we would know someone else is using the software. However, if that other user is working with data in a different folder, we don't care so we do not want to lock the exe.
Hope that is clear
[excessive quoting removed by server]