Control a from on another Access file, on another PC (1 Viewer)

Acke

Registered User.
Local time
Today, 18:32
Joined
Jul 1, 2006
Messages
158
Hi guys!

Simple code that successfully controlls the form on another Access file, on the same PC is:

Code:
Funcion RefreshAnotherForm(strDbPath As String, strFormName AS String)
Dim objAcc As Access.Application

Set objAcc = GetObject
objAcc.Docmd.OpenForm strFormName
objAcc.Forms(strFormName).Form.formField = "Message..."
objAcc.DoCmd.Requery

End Function

Code to trigger this function is:

Code:
Private Sub bttRefresh_Click()

RefreshAnotherForm "C:\MyDocuments\dbName.accdb", frmCustomers

End Sub

I would need the same event to be triggered from PC1 to be applied on the PC2, on another access file. Both access files are located on the PC1.

I would like to avoid using the timer as it makes the application glitchy, but also would like to learn a new trick.
 

arnelgp

..forever waiting... waiting for jellybean!
Local time
Tomorrow, 01:32
Joined
May 7, 2009
Messages
19,169
the easiest is through timer event.
there is no guarantee that it will work on another pc.
you must have same elevated right on the the other pc in able to control it.
even if it succeed, there is no guarantee that the db will remain on it's current
location.
 

Acke

Registered User.
Local time
Today, 18:32
Joined
Jul 1, 2006
Messages
158
Thanks arnelgp!

the easiest is through timer event.

The timer is what I am trying to avoid.

there is no guarantee that it will work on another pc.
you must have same elevated right on the the other pc in able to control it.
even if it succeed, there is no guarantee that the db will remain on it's current
location.

The system is under my full control all the time. No worries about the location of the db. All files are having full rights.

What I need is the code that will refresh the form data on another db, on another PC. The form is a continuous form. The fields on the form are bound and the form must be refreshed. I also need to update an unbound field on that form (another db, on another PC).

Is there are code that can accomplish this task?
 

arnelgp

..forever waiting... waiting for jellybean!
Local time
Tomorrow, 01:32
Joined
May 7, 2009
Messages
19,169
afaik, it may or may not be possible.
i have yet to see the answers of the others.

you need a timer and a Linked table from db of pc2 to db of pc1.
this table can have a yes/no field signifying if a Refresh is need to be done to the form.

the timer can be very quick.
inquire the value of the yes/no field.
if the value is no exit the timer and wait for another
timer interval.
if the value is yes, get another value from another field
and update the form.
then reset the yes/no field to no.

what you are enquiring maybe possible, but i have only no other pc to test.
the principle is, open the db from the remote pc.
check if the form is already open (maybe some flag on a table when
this form opens).
if open update its control value.
 

Acke

Registered User.
Local time
Today, 18:32
Joined
Jul 1, 2006
Messages
158
Thanks!

you need a timer and a Linked table from db of pc2 to db of pc1.

All files are frontend and are linked to the backend db file containing only tables.

the timer can be very quick.
...

The timer can do the trick. Still, I would prefer to learn the code to control the form as mentioned.



what you are enquiring maybe possible, but i have only no other pc to test.
the principle is, open the db from the remote pc.
check if the form is already open (maybe some flag on a table when
this form opens).
if open update its control value.

This is exactly what I am after. I can try a code you think may work. If you are happy with that, please let me have the code to test it.
 

Gasman

Enthusiastic Amateur
Local time
Today, 17:32
Joined
Sep 21, 2011
Messages
14,044
So why can you not map the drive of PC2 and then use your method?
Will it work with the UNC path?
 

Acke

Registered User.
Local time
Today, 18:32
Joined
Jul 1, 2006
Messages
158
So why can you not map the drive of PC2 and then use your method?
Will it work with the UNC path?

My method opens the database on the PC1 where it is triggered. The activity needs to be performed on the PC2. And that is if the targeted db is closed. As it is always the case that the targeted file is already opened on the PC2, the file is locked and the event makes a mess in addition to not accomplishing what is required.

Not that it would make any difference to the outcome of my method, but to mention... All 3 dbs are located on the PC1 and it must remain like that. Backend with tables, triggering frontend db, and targeted frontend db.

Not sure what is UNC path. I am not a professional programmer :)
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 13:32
Joined
Feb 19, 2002
Messages
42,971
I would need the same event to be triggered from PC1 to be applied on the PC2, on another access file. Both access files are located on the PC1.
In the first sentence you say the files are on two different PC's and in the second, you say they are both on the same PC??? Which is it?

Just FYI, Forms do not store data. Tables store data. Access automatically refreshes forms. Change the time delay if you want it to happen faster. This of course will make the form much less efficient. Change the data in the BE and the FE on the other PC will pick up the changed value as soon as the refresh runs. I'm pretty sure you are making this harder than it needs to be because you think that forms store data.

Perhaps if you told us in words what problem you are trying to solve we could provide better advice. Right now, despite your lack of programming experience, you have decided that you know what the proper solution is and you are asking us to make your solution work. There may be a simpler solution.
 

Isaac

Lifelong Learner
Local time
Today, 10:32
Joined
Mar 14, 2017
Messages
8,738
This thread is a little confusing, but let me boil it down to one question at this time:
Are you saying your original code actually works?

To directly do something on one machine (pc, server, etc) from another machine (pc, server, etc), you have to have network access of some kind, period. (without, of course, using some in between layer - team viewer, rdp etc)

If you have network access, you can use the full unc as others said or you can map a drive using code 'on the fly', if it's the case that you can only access that 'full unc' path, using credentials.

It's very confusing what file is where and where you want to trigger what from where.
 

isladogs

MVP / VIP
Local time
Today, 17:32
Joined
Jan 14, 2017
Messages
18,186
I'm also confused by some of the OP's responses.
Why not link to the table(s) in the database on the other computer & import the form from that computer
 

Acke

Registered User.
Local time
Today, 18:32
Joined
Jul 1, 2006
Messages
158
In the first sentence you say the files are on two different PC's and in the second, you say they are both on the same PC??? Which is it?

All 3 files are located on the PC1. Let's call the files beDB, feTargetDB and feTriggerDB. The beDB is a file containing tables only. All data is being stored only on the beDB file. Both feTargetDB and feTriggerDB contain tables linked to the beDB. The file feTriggerDB runs on the PC1. The targeted file (feTargetDB) is being opened and runs on the PC2.

Just FYI, Forms do not store data. Tables store data. Access automatically refreshes forms. Change the time delay if you want it to happen faster. This of course will make the form much less efficient. Change the data in the BE and the FE on the other PC will pick up the changed value as soon as the refresh runs. I'm pretty sure you are making this harder than it needs to be because you think that forms store data.

The form that needs to be refreshed is a continuous form. Access does not refresh continuous forms automatically.

Perhaps if you told us in words what problem you are trying to solve we could provide better advice. Right now, despite your lack of programming experience, you have decided that you know what the proper solution is and you are asking us to make your solution work. There may be a simpler solution.

When new data is entered on the feTriggerDB (file located on the PC1, runs on the PC1), I need that information immediately visible on the form (continuous form) in the file feTargetDB (file located on the PC1, runs on the PC2).

Or, as arnelgp wrote:

what you are enquiring maybe possible, but i have only no other pc to test.
the principle is, open the db from the remote pc.
check if the form is already open (maybe some flag on a table when
this form opens).
if open update its control value.
 

Acke

Registered User.
Local time
Today, 18:32
Joined
Jul 1, 2006
Messages
158
This thread is a little confusing, but let me boil it down to one question at this time:
Are you saying your original code actually works?

Works like a charm. But only on the PC where it is triggered. I need to control the file on the remote PC.

To directly do something on one machine (pc, server, etc) from another machine (pc, server, etc), you have to have network access of some kind, period. (without, of course, using some in between layer - team viewer, rdp etc)

Both PCs are on the same location with full network access all the time they are active. The network is secure and without internet access. I am also in the same location as the PCs. No restrictions from that point.

If you have network access, you can use the full unc as others said or you can map a drive using code 'on the fly', if it's the case that you can only access that 'full unc' path, using credentials.

This is the part that I, as an Access enthusiast, do not understand :). What is unc path?
 

Acke

Registered User.
Local time
Today, 18:32
Joined
Jul 1, 2006
Messages
158
I'm also confused by some of the OP's responses.
Why not link to the table(s) in the database on the other computer & import the form from that computer

All files are already linked to the backend DB.

I need an immediate response on the remote PC, as mentioned above.
 
Last edited:

isladogs

MVP / VIP
Local time
Today, 17:32
Joined
Jan 14, 2017
Messages
18,186
A relative path includes a local or mapped drive letter e.g. C:\user\docs\Letter.txt, X:\MyFiles\Letters\Letter.docx.
The problem with usin g mapped drive letters is these may vary from one PC to another
A universal naming convention or UNC path overcomes that issue. It uses server name e.g. \\Server01\user\docs\Letter.txt; \\Fred-PC\C\MyFiles\Letters\Letter.docx

See https://en.wikipedia.org/wiki/Path_(computing)

As I'm still unclear what you are trying to do, I will drop out of the thread now.
 

Acke

Registered User.
Local time
Today, 18:32
Joined
Jul 1, 2006
Messages
158
As I'm still unclear what you are trying to do, I will drop out of the thread now.

I am sorry for the confusion. What I need is to refresh the continuous form on the remote computer, if that form is active on the remote computer.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 12:32
Joined
Feb 28, 2001
Messages
26,999
If I am reading this correctly, the form in question is being displayed (already) on a form opened on a remote PC. Which means you have a session created already that launched Access and somehow brought up that form, by manual or automatic means. You are asking us how to do something to the session on the remote PC from your local PC.

From a security standpoint, Windows will not normally allow you to do this. Access is in a private task (session, process, pick your favorite name for that concept) for which the physical entity that launched the session is in control of the session. That means that the interface that would normally do this kind of control is either the keyboard & mouse (if launched via icon or command line) or a null command channel (if launched via Task Scheduler or a similar mechanism). It is not unknown to have Access run based on a scheduled event, but normally in that case you run a "startup" macro after which you tell the macro to shut down the application. That is because Access in that latter case is a background task. It has NO control channel.

Windows is compliant with U.S. Government regulations (and probably other governments as well) regarding "object isolation and reuse" principles. What you want to do would massively violate the isolation rules even if you are logged in as the same exact user on both systems. Which, by the way, can actually only happen on a domain network. Even if you spell your username the same on two independent Windows system, local username SID (System ID) will include both a user sequence number assigned when your account was created PLUS the machine's SID. So they would be two different numbers internally. Which means that your account on the local PC is NOT the same as the local account on the remote PC.

There are Windows API calls that would let you take control of that session, but it is not enough that you would be an administrator. You would need some serious Windows Privileges (using that as a specific word for an element of Windows per-user security). If you have a domain administrator who controls your system accounts, his/her first three answers will be "NO", "Hell NO", and "Not on your life."

If you had remotely opened this session somehow using an Access application object, you could make it work, with a little effort to bring up the display. BUT that display would be disconnected from the keyboard and mouse because THEY didn't launch the remote session. There are API calls that one could make to perhaps reestablish the command channel, but you are essentially looking at some rather seriously difficult code that runs afoul of Windows security.

You MIGHT, if you got REALLY ambitious, somehow establish a network socket to the remote PC and launch the session that way, but again, the mouse and keyboard control issues would become a real pain in the patootie. I have to agree with earlier comments that your best bet looks like a timer event in the remote application. Whether you do something tricky with the back-end or just use the timer directly, you are going to have a real headache trying to get this working.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 17:32
Joined
Feb 19, 2013
Messages
16,553
I think it would help if you explained why you are doing this. My first instinct was that you wanted to bring up a message on the other machine. Now it appears you want to take control of the other app in order to requery a form if it is open.

What does this other PC do? Who's looking at it? Who's controlling it? Who opened the app originally?

I suspect the answer is it can't be done unless you can jump through the hoops outlined by Doc
 

Acke

Registered User.
Local time
Today, 18:32
Joined
Jul 1, 2006
Messages
158
Thank you for the detailed response The_Doc_Man! I appreciate your effort.

If I am reading this correctly, the form in question is being displayed (already) on a form opened on a remote PC. Which means you have a session created already that launched Access and somehow brought up that form, by manual or automatic means. You are asking us how to do something to the session on the remote PC from your local PC.

Yes.

From a security standpoint, Windows will not normally ...... you are going to have a real headache trying to get this working.

It sounds complicated and I hope this is not the only way to avoid using the timer. If so, the timer will be the solution.
 

Gasman

Enthusiastic Amateur
Local time
Today, 17:32
Joined
Sep 21, 2011
Messages
14,044
I am keen to understand why using a timer will circumvent all the issues that Doc raised?
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 13:32
Joined
Feb 19, 2002
Messages
42,971
Access does not refresh continuous forms automatically.
Yes it does. It doesn't "requery" forms automatically but it does refresh them regardless of display format. Only Requery shows "new" records. Refresh does not.

It is really poor practice to have a single database file opened by multiple users. Only the BE is ever shared in a properly set up application. The FE is NEVER shared. Plus, unless you are running something like Remote Desktop or GoToMyPC, you can't actually cause software on a different PC to run on the remote PC because Windows doesn't want that to happen as Doc pointed out.
 

Users who are viewing this thread

Top Bottom