How to know if table is still in use? 6

[Mandy_crw]

Hi experts... i dont know, i consider my app as finish, but everytime I use it, there is always that i see to be added... so here i go again to ask...

Since my app is in the server computer, sometimes the server computer is being closed first, so the client computer that uses the table in the server displays an error message when app ive created is closed or when used , because table are already closed in the server... Pleas teach me or show me how or give me suggestion to avoid this... is there a way to know that there are still using the table? Thanks and God bless....

 

[GriffMG]

Try opening the tables exclusively, if they open on the server then noone else is using them...

You would need error handling to do this

ON ERROR DO FILEERR
SET EXCLUSIVE ON
USE MyTable
IF !USED("MyTable")
	** users still in
ELSE
	** no users working
ENDIF

	
PROCEDURE FILEERR
	RETURN

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.

There is no place like G28 X0 Y0 Z0
​

 

[Mike Lewis]

Mandy, are you asking how to determine if the table is in use by your program?

If so, [tt]AUSED(laArray, 1, "tablename")[/tt] should return 1 if the table is open, otherwise 0. laArray is the name of an array. "tablename" is the name of your table, preceded with its path if it is not in the VFP search path.

Or, are you asking how to determine if the table is open in another VFP session (either the same computer or, in this case, the server)?

If so, something like this:

llError = .F.
TRY
  USE TheTable EXCLUSIVE
CATCH
  llError = .T.
ENDTRY

If the table is open in another session (including on another computer), llError will be .T.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mandy_crw]

Thank you Mike and Griff... I want the server not to shutdown if in case an app of mine is still open in another computer...


llError = .F.
TRY
USE TheTable EXCLUSIVE
CATCH
llError = .T.

messagebox("Another session is open on another computer... Please close it first before shutting donw...",0"message")
return​

ENDTRY


is this correct Mike?

 

[Mike Lewis]

Not quite right, Mandy. Mainly because you shouldn't do RETURN inside a TRY / ENDTRY (at least, that has always been my philosophy, rightly or wrongly). Try this instead:

llError = .F.
TRY
  USE TheTable EXCLUSIVE
CATCH
  llError = .T.
ENDTRY 
IF llError
  messagebox ;
   ("Another session is open on another computer... Please close it first before shutting donw...",0"message")
  RETURN
ENDIF

Also, pay attention to where you are returning to. Is this code part of a procedure or method, and would returning from that procedure or method prevent the current session from closing down?

I'd also question the whole reason for this situation. Why are you in a situation where you have to close the server session before you can close the local session? What problem does that solve?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mandy_crw]

Hi Mike... Thanks... I am just thinking that a user might close his session in the server, hence session in other computer may crashed for there are no more tables open... so i want to tell the server user not to shutdown that computer server if seions are still open in other computer... Thank you Mike...

 

[Chris Miller]

What does the usage state of your server version has to do with the client version?

You seem to think or you seem to want that if your server version doesn't have a table open, clients can't also use it. Well, actually if nothing has a table open, not even your server, the client has it even easier to get the file, it could even get the file exclusive and not only shared.

On the other side, if your server has a table opened exclusive, no client could have it.

So what are you actually doing in the server version. Are you opening all files shared? What is actually the reason for your server application. Is it acting as a database server that handles data access to all your clients? Do your clients get tables "forwarded" in some way from your server? So is your server like an SQL Server?

If so, I can totally understand why you want to have it running. Well, what hinders you to keep it running? Clients should not need to run it and not at all be capable to close it, a normal SQL server also only "offers" its services, clients can connect to it but not close it. At least not unless they have the server admin role and can send in a query to shutdown the server. The server also runs, well, where if not on the server, separate from all clients, so how and why would clients have an easy way to quit the server?

Could you explain what your server is actually doing and how?

Chriss

 

[Chris Miller]

I want the server not to shutdown if in case an app of mine is still open in another computer..

If I understand this correctly, you want the server to stay available whenever it is still needed. Well, I think my puzzling comes from a standarad you don't seem to know or use: A server, also just a file server, is something that usually runs uninterrupted and is never shut down except for maintenance.

I want to tell the server user not to shutdown that computer server if sessions are still open in other computer.

Well, from what I just said you simply have to tell the user that works on a server (which is unusal), that it's the server and is not a workstation like others, it's not shut down at all.

That might not be the case for you, perhaps as reason for saving energy, but if the server should be available when a user starts the application, well, you can't even shut it down when you're sure no user is currently needing the database and tables files at all, because that can change at any moment.

In short: It's very usual the server runs 24/7 and no user works at it. But if you need this, then one simple to implement solution is schedule the shutdown of the server to after work hours. If it's a good server hardware it might also allow wake-on-LAN and be started by schedule again in the morning before any user works.

You also say yourself clients may just have crashed or are idle not using tables, then you still don't want to shutdown, so the only real sure state is by time schedule, isn't it?

So, okay, lets limit it to one case: A user wants to know whether currently no files are used before shutting down the server, then there's this tool about finding out who has open file handles on a server:

https://www.berezniker.com/content/pages/visual-foxpro/who-has-files-open-network.

Please read the details in this blog article, it has important requirements about permissions of the user doing that code besides other restrictions, it's important you understand them.

Trying to get all exclusive access to all database files is more specific to your application, but this will also in general list user having open server files, which could also be office documents or others. And when this server isn't just acting as a file server but as primary domain controller, the server into which users log in, you surely have more to the point solutions from server administration side than you have looking into just the database files. But then also even less reasons to shut such a server down.

Chriss

 

[Mandy_crw]

Hi Chriss

So what are you actually doing in the server version. Are you opening all files shared? What is actually the reason for your server application. Is it acting as a database server that handles data access to all your clients? Do your clients get tables "forwarded" in some way from your server? So is your server like an SQL Server?

Yes Chriss, all files are open in shared, it is acting as a database server... I dont know much about SQL Chriss...

I have this Cmdexit in my Client computers app

PROCEDURE cmdExit.Click()

DECLARE Integer ExitProcess IN WIN32API
ExitProcess()

ENDPROC

So that it will not close the databases in the server everytime the user click the x button in the clients app... is this correct Chriss?

 

[Chris Miller]

You surely don't have programmed a database server, the server version of your app just runs on the computer that has the database files, right? That doesn't make it a server. The computer would also act as the computer having the files other clients use, if it only had these files and no installation of the whole software.

Again asked: What is different to other computers in the behavior of your application?

Your code (and please see Mike Lewi's advice in thread184-1817705) is exiting the process. That also closes the tables and database locally for this process, but not for everyone else, all their open files remain open. Any VFP software is it's own software unless you'd actually program a VFP database server.

Code you earlier posted was shutting down the whole computer using run /N7 shutdown -s -t 01. Are you even aware that this shuts down the whole computer? That causes what you currently want to avoid, that doesn't only close its own usage of the database, that shuts down the computer and causes problems for all other clients still running. I don't know, but maybe that's your problem. Your problem in detail then is who's putting a record in pendlog table that causes that shutdown to happen too early?

Chriss

 

[Mike Lewis]

Mandy,

Having read your most recent posts in this thread, and also Chris's replies, I have to say that I am totally confused about what you are trying to achieve.

I think the most important point here is: why are you even considering closing the server? Given that this is a file server, it should just remain open the whole time. Think of it like the electrical outlet in a wall socket. If, for some exceptional reason, it ceased to be available, then your client application cannot run - just as it cannot run if there was no electricity available. You may well want a way of recovering from that situation, but you wouldn't expect a client application to actually control the supply of electricity - or the supply of data.

Also, you say you have an app running on the server. What is that app, and why is it there? If this is indeed a file server, the only software running on it would be the server operating system and its supporting components - not a custom-made VFP app.

Perhaps there is a fundamental misunderstanding here about the nature of a file server.

One final point: Using ExitProcess() to close an app is very unusual. The function would indeed end the process, but I have never come across any need to use it within VFP.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Steve Meyerson]

Mandy,

It's not ideal, but I happen to have an app which runs on 3 computers in a local area network. One of the computers acts as the server as I think is your situation. It contains the dbfs (no SQL) used by all 3. If the user on the server machine exits the program, the other 2 can STILL access the data. I think you can do this if:

1. Put the data on the server in a DIFFERENT folder than the program on the server. Set the data path to that data folder in your app on the other machines.

2. Don't turn off the server machine when its user exits the program. If that is not possible in your situation, disregard all the above.

HTH

Steve

 

[Mike Lewis]

I agree with those points that Steve has just made. In fact, they reinforce what I was trying to say in my previous post. The only point on which I would disagree is placing the data in a different folder from the program (on the server). In fact, that's a useful thing to do, but it is not necessary in order to solve this particular problem (unless I have misunderstood the situation, which is quite possible).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Steve Meyerson]

I forgot to mention: Each user might have a different path to the data. In my app I use GETDIR() to allow each user to specify their own path to the data.

Steve

 

[Steve Meyerson]

(unless I have misunderstood the situation..

No, you are absolutely correct. Good point. It just happens to be the way I did it. Either way should work.

Steve

 

[Mandy_crw]

One of the computers acts as the server as I think is your situation. It contains the dbfs (no SQL) used by all 3. If the user on the server machine exits the program, the other 2 can STILL access the data

yes Steve this is my case... but i always get an erron when i close the app in the other computer...

in my close routine i have included
CLOSE DATABASES ...

is this correct steve?

 

[Steve Meyerson]

in my close routine i have included
CLOSE DATABASES ...

Does the error occur exactly when the CLOSE DATABASES is issued? Or before or after?

Exactly what is the error message?

 

[Chris Miller]

CLOSE DATATBASES or pretty much ANY command only acts in the process it executes. It does NOT close tables and databases for all, just for itself.

A VFP database is just the files, available on the LAN. No more, no less. As I said:

The computer would also act as the computer having the files other clients use, if it only had these files and no installation of the whole software.

Or take what Mike Yearwood said.

Just because you close your eyes, things are still there and whether others can see them only depends on whether they still keep their eyes open.

The food is on the table, no matter if the butler is there or not. And your butler is just another guest with one more tab in one pageframe, as far as I know. The other guests all take their food themselves.

You would need to do something strange if closing your server mode EXE causes other clients to lose their data access. Like creating a share when the server version starts and removing the share, when it ends.

You can set up a permanent share with permanent allowance of users belonging to a specific group and then maybe also create permanently mapped drive letters on the clients and after that just turning on the server role workstation and keeping it on means data access for all. And it should be clear from previous posts, that turning off a server isn't normal.

Chriss

 

[Chris Miller]

creating a share when the server version starts and removing the share, when it ends.

Do you do that? The question I had what your server version does that client versions don't is still open. All I know is there is an extra tab on one form.
What feature does the server have, that clients don't? What does it do what clients don't?

The file access is done by hardware and OS, for all versions. Unless you do data access differently, but then please tell us. We don't know the difference of your server and client version.

Chriss

 

[Mandy_crw]

Does the error occur exactly when the CLOSE DATABASES is issued? Or before or after?

Exactly what is the error message?

I was wong Steve the error shows when the app is open in the client, then the server is shutdown first... cannot access file... understandable because the file server is no longer on... Thanks Steve...