Who keeps Access opened 2 ?

[Edgar_]

If an organization wants to build a database application it must choose two types of tools.

Development, testing, deployment, monitoring, debugging, maintenance and administration, among many other things, often require extra tools. Furthermore, certain pieces of information require access to the internet if you want to work with actual data, including syncing databases outside your network, in fact, if you want to do that with Access, some of you often opt for RDP despite its potentially insecure nature. In this day and age, implementing integrations is the norm. It certainly is the case here, where the Access database was discarded to favor an external one.

adding another tool to solve some subordinate technical requirement is an entirely different matter. It is not a mandatory key component for this type of project. Decision makers may very well choose to avoid this additional and optional risk.

Well, that depends entirely on the platform you're using. Many platforms let you build a websocket within them, think ASP.NET (can be done with VB), ExpressJS, DJango, Flask, etc. Access may not particularly let you write your own with ease, but it does let you integrate your own implementation using its built-in controls as demonstrated. And I insist, it does not have to be Firebase, you've been told multiple times that you can write it yourself.

The application becomes dependent on internet connectivity and the availability of an external service. Data, even if it is not very sensitive, is stored outside the companies full control, potentially even outside the company's country of jurisdiction. This a a huge deal with a ton of red flags attached in many organizations.

You're probably unaware that computers connected locally can share a local websocket.

I appreciate your efforts to let me know about the problems you've encountered as a developer. Please, keep in mind we all have had different journeys and the things you've had issues with may not extrapolate to other developers. I do believe your concerns are important, but I perceived your posts were dismissive and discouraging. It may not seem obvious for you, but the example may be beneficial for someone else, given the ample usage of the technology in so many other platforms, particularly in web environments. Moreover, it's a highly resourceful alternative that can be implemented with very few lines of code.

Edited post.

 

[The_Doc_Man]

How to detect (from any workstation) which workstations have the Access program running in memory?

The above was part of the original question in post #1 of this thread. All sorts of solutions have been offered, but I need to add another layer to this discussion. On review of the thread, I realize an important facet has not yet been discussed.

Windows, ever since Win NT, has had several security principles in place that relate to inter-process interactions. The simplest statement is this: Windows wants to isolate one user from another. Therefore, it is forbidden for an ordinary user to interact with the task of another ordinary user.

On your workstation, you are the ONLY user, which means you can see ALL of the processes you create. Your processes are not protected against you because you own them. If you are listed as the machine's OWNER then you can see all of the system processes in detail as well because that ownership makes you a LOCAL sys admin.

HOWEVER, on a server, you will only be able to see that which is posted with permissions to read it. That includes details of the task's username and other factors. On that server-based system, many users will potentially have some kind of session active. Most of them will NOT be administrators, operators, or other privileged individuals. More specifically, most users on a server will not have the privilege of acting as user SYSTEM (on that server) or the privilege to read all structures regardless of ownership. There are many of these privileges, each granting someone some extra ability not available to an ordinary user. But if you are using Access, you probably ARE acting as an ordinary user. This means you can't look at or interact with another user's process on a server.

Many of the discussions in this thread talk about tools to use. If you are the server's sys admin or a domain admin, you can probably use those tools. But if you are Joe Average User (or Jane Average User) then those exploration tools will be denied access to what you seek.

Therefore, the above question breaks down this way: If you are a general user and didn't build a solution of this problem into the app, you can't detect anything at all, because Windows has these methods but they are protected against general users using them.

 

[cheekybuddha]

And I insist, it does not have to be Firebase

@Edgar_ ,

You appear to be confusing Firebird with Firebase.

They are completely different products (made by different companies).

Firebird is a rdbms much like MySQL or Postgres, and is unlikely to be run as a cloud service.

So, while you can add another transport layer (eg webservice) to communicate with it, it would be an extra headache and stack to deal with. Especially when Access can communicate directly with Firebird via ODBC.

 

[June7]

Title of this thread should not have been "Who keeps Access opened 2", should be "Who keeps Firebird backend open".

 

[amorosik]

Title of this thread should not have been "Who keeps Access opened 2", should be "Who keeps Firebird backend open".

No
The question is:
"..How to detect (from any workstation) which workstations have the Access program.."
Firebird, Sql Server, Postgresql, doesn't matter

 

[amorosik]

But if you are Joe Average User (or Jane Average User) ...

Or JoaX Average user

 

[amorosik]

The best solution I've found so far has been to add an 'AvailableClients' table to the database, each client that is started checks if the record with its IP address is present, if not present then it adds the record
Each client, when started, uses the MSWinsockLib to listen for a tcp socket
When any client wants to 'see' which other clients are active at the moment, it reads the AvailableClients table and queries the other clients, as per db table reading
If they respond to them then they are active
I used this system because it does not use specific features of a single database server and therefore allows me to use exactly the same code/program with other types of databases too

 

[gemma-the-husky]

The above was part of the original question in post #1 of this thread. All sorts of solutions have been offered, but I need to add another layer to this discussion. On review of the thread, I realize an important facet has not yet been discussed.

Windows, ever since Win NT, has had several security principles in place that relate to inter-process interactions. The simplest statement is this: Windows wants to isolate one user from another. Therefore, it is forbidden for an ordinary user to interact with the task of another ordinary user.

On your workstation, you are the ONLY user, which means you can see ALL of the processes you create. Your processes are not protected against you because you own them. If you are listed as the machine's OWNER then you can see all of the system processes in detail as well because that ownership makes you a LOCAL sys admin.

HOWEVER, on a server, you will only be able to see that which is posted with permissions to read it. That includes details of the task's username and other factors. On that server-based system, many users will potentially have some kind of session active. Most of them will NOT be administrators, operators, or other privileged individuals. More specifically, most users on a server will not have the privilege of acting as user SYSTEM (on that server) or the privilege to read all structures regardless of ownership. There are many of these privileges, each granting someone some extra ability not available to an ordinary user. But if you are using Access, you probably ARE acting as an ordinary user. This means you can't look at or interact with another user's process on a server.

Many of the discussions in this thread talk about tools to use. If you are the server's sys admin or a domain admin, you can probably use those tools. But if you are Joe Average User (or Jane Average User) then those exploration tools will be denied access to what you seek.

Therefore, the above question breaks down this way: If you are a general user and didn't build a solution of this problem into the app, you can't detect anything at all, because Windows has these methods but they are protected against general users using them.

Yes, so the programmer who looks after Access asks the system administrator to sort it out. The programmer might be the sysadmin. What you do need is to understand what's causing the problem and how to resolve it, which a general user won't.

And the users need some general education. Many users don't even understand a folder structure, and are best protected from themselves.

 

[Edgar_]

You appear to be confusing Firebird with Firebase.

David, let me clarify that and other points:
1. The solution I proposed in post #2 involves a websocket that can be written using any technology that supports it.

2. The example I posted in #22 utilizes a Firebase's websocket to keep me from developing one myself (I don't want to write and deploy a custom websocket for an example in the forum), but the one I posted can be utilized effectively too, and I encourage anyone to try it.

3. The code responsible for this communication resides in the frontend. Why is that relevant? Because there is confusion about the relevance of Firebird in my example. And Firebird is irrelevant. How? an Access frontend can establish a connection with any external tool that allows it, provided they have the credentials for it. Therefore, it does not care about the backend being used. Your frontend could be gathering data from one million backends or none at all, if you needed that. The existence of Firebird has null importance in the solution.

4. In the solution I proposed in post #2, a web browser control is used because it can react to external stimuli, in this case, something happening to the Firebase backend. In the example I posted, when you change the value of one node in that cloud service, the websocket makes the web browser react to that stimuli through an event, the event is then listened by Access and you can choose what to do with it. That is the concept.

So, while you can add another transport layer (eg webservice) to communicate with it, it would be an extra headache and stack to deal with. Especially when Access can communicate directly with Firebird via ODBC.

Yes. But so is the case with any other line of code you have to maintain. Code is a liability, not an asset. It's up to the developer to choose what to do with the options they have. It is a shame that Access does not have a fully featured capability to inform who is connected, so it's good to have options.

 

[The_Doc_Man]

The best solution I've found so far has been to add an 'AvailableClients' table to the database, each client that is started checks if the record with its IP address is present, if not present then it adds the record
Each client, when started, uses the MSWinsockLib to listen for a tcp socket
When any client wants to 'see' which other clients are active at the moment, it reads the AvailableClients table and queries the other clients, as per db table reading
If they respond to them then they are active
I used this system because it does not use specific features of a single database server and therefore allows me to use exactly the same code/program with other types of databases too

Which is exactly what I said in my post about the security issues. If you don't build a solution into the app, the answer is "you can't find out anything." YOU built your solution into the app because you CAN'T get Windows to do it all for you. So to you, amorosik, I say

 

[gemma-the-husky]

Don't excel power users have the same issue.
They get "another user has your file open. Do you want to open it read only?"

Don't they have the same issues determining who has opened the spreadsheet?

 

[amorosik]

Which is exactly what I said in my post about the security issues. If you don't build a solution into the app, the answer is "you can't find out anything." YOU built your solution into the app because you CAN'T get Windows to do it all for you. So to you, amorosik, I say

This is ONE possible solution
Also Kitayama is a possible solution, maybe better, who say

 

[The_Doc_Man]

Don't excel power users have the same issue.
They get "another user has your file open. Do you want to open it read only?"

Don't they have the same issues determining who has opened the spreadsheet?

Not quite the same, but pretty darned close. Access is built to allow file sharing in the strict sense of having two people actively updating something at the same time from two different workstations. Excel was not originally designed to allow that kind of sharing. It allows multiple readers but only one writer at a time. A read-only user won't make a big difference because their read-only lock won't allow them to change things in that file. But you still have the same problem in finding the session that has the workbook open for writing.

 

[Isaac]

Suppose we have a server database and many workstations each with its own copy of the Access procedures
In this situation it is not possible to use the laccdb file because each workstation will have its own
How to detect (from any workstation) which workstations have the Access program running in memory?

What I have done is just maintain a table of who opens and closes the database when it opens and closes. Then you know who has it currently open. Unless they kill it or ctrl+alt+delete etc., but that's the exception

 

[gemma-the-husky]

@The_Doc_Man
Yes that's I meant. Similar issue tracing the owner, but not quite as critical because you can save a different filename, although then you would have problems joining all the edits together if necessary.

I can't remember having had excel issues though. I assume users know better what they are doing with excel though.

 

[The_Doc_Man]

I assume users know better what they are doing with excel though.

Some years ago my dear wife taught Office software for CompUSA (when they still had a brick-and-mortar presence). From what she told me about her students, I would have to say that your assumption might be a slight bit shaky.

 

[amorosik]

What I have done is just maintain a table of who opens and closes the database when it opens and closes. Then you know who has it currently open. Unless they kill it or ctrl+alt+delete etc., but that's the exception

If client stop with any error non recoverable, there is not a 'close' for that client

 

[The_Doc_Man]

If client stop with any error non recoverable, there is not a 'close' for that client

I found that it was impossible to prevent the "ugly" close but I solved that by considering that (a) no session could last more than 12 hours (by employment rules and government regulations) and (b) the nature of the DB in question was not something that a person would open twice from the same workstation at the same time.

For the big Navy DB, when a user launched the session, I took the domain and workstation IDs from some API calls and appended to a "Who's Logged In" table. If you later exited normally, ALL of your open sessions were closed. If you launched and had some open session entries still hanging around, they were closed with a special code. And as the DB Admin, I had a routine I could run to terminate session records greater than some time limit which I could choose from 12 or 24 hours old, again with a special code. When we had a bollixed-up (bad) exit case, I also had limited extra rights to terminate user sessions on the server in question, which I could identify because I knew the user's domain login name and the ID of the computer. That way I could usually get away without having to warn users of an imminent emergency shutdown because I could kill the offending session.

I didn't erase the records of usage. I had session logs (which the Navy was very insistent on having) showing user, computer, enter and leave time logs, and termination code - all of which got archived on a regular basis. If an abnormal close was used to close a session, codes showed how the session ended - normal exit, multi-session overlap exit, or time-limit exit. That let the Navy have all sorts of useless but pretty usage charts that correlated with when things were done most often. And the username/computer ID combo gave me what I needed to terminate sessions selectively.