Refresh a form from another database?

[Stephen Parker]

1234567890

[NeoPa]

Stephen Parker:
It is my belief that there should be something simple to allow (FileB) to refresh the data in the form of (FileA)

Not mine I'm afraid Stephen. Referring to FileB from FileA should be fine, but the reverse is not true as far as I'm aware.

Why are you not looking at doing a .Requery of your form in FileA from the form itself when it has completed its call to FileB? Is it because the processes in FileB are running asynchronously?

[Stephen Parker]

123456789.

[ADezii]

I haven't had a chance to research this Logic, but you may wish to try something like this in order to Refresh a Form in an External Database.

'Modular Level
Dim appAccess As Access.Application

Dim frm As Access.Form     'Will be a Reference to the Form in External Database
 
'Create new Instance of Microsoft Access.
Set appAccess = CreateObject("Access.Application")
 
'Open Database in Microsoft Access window.
appAccess.OpenCurrentDatabase "C:\Stuff\Copy of Northwind.mdb"
 
'appAccess qualifier is critical in referring to the Form in External DB
Set frm = appAccess.CurrentDb.Containers("Forms").Documents("Orders")
 
frm.Refresh

[Stephen Parker]

123456789.

[ADezii]

I assume that you already have an Object Variable pointing to the New Instance of the Application (Access), can't you just swap out and see what happens? Can you post the relevant code so that we can see exactly what is happening, and as to how we can possibly integrate a solution into it?

[Stephen Parker]

123456789.

[NeoPa]

Stephen Parker:
Yes.

Yes? Is that a yes to my question "Is it because the processes in FileB are running asynchronously?"? I'll have to assume so although frankly, that is not a clear way to communicate.

Stephen Parker:
It sounds so strange for Microsoft to make the Access modules code/functions available via a Reference but not the modules code/functions behind the forms as these are also modules

Hold your horses. Who told you that was the case? And why do you bring it up here? It's irrelevant as you don't even have a reference to that database (at least that you've shared so far), even to access standard code modules.

Let's take a step back. Form and other object-based modules are accessible, just as the standard code modules are, you just need to know how and to understand that forms are a class, not the instance of the class as we are used to treating them as. If you want to know how to access the public methods of a form class then look at the class name in the VBA IDE that is shown for each module-enable class. Typically forms have their generally known name (EG. frmMain) with Form_ at the start, so Form_frmMain. Form methods may be accessed this way. To access a form method, or any code, of a database you have no access to though, is a whole different ball game.

A potential solution would be to try passing the calling form itself, as an Form object, to the called routine in the other database (FileB) as a parameter. That way, it may be possible to call a .Requery of the passed form object reference directly the process has completed.

[NeoPa]

Stephen Parker:
As for posting relevant code there is no relevant code to post. All relevant information is contained in the initial post.

You have no code (seems unlikely)? Or you decide it's not relevant to post it even though you've been asked (seems pretty uncooperative)?

It seems to me your code would indeed be particularly relevant here. Presumably you ask us for help on the understanding we may know something you don't. I suggest using your existing understanding to decide what we need is not the best approach. Your original post is certainly not well enough explained, nor detailed enough, to help me tell you how to handle this, but from snippets you've dropped, I think I can, with an understanding of how your two database instances link together. You could explain it in text without the relevant code, but so far you haven't. It really would be easier if you took a more cooperative attitude and just posted the code as requested. I know we want to help you. I can't see why you wouldn't want us to.

[NeoPa]

Something didn't feel right about this. Some of your posts seemed a bit unhelpful, but I reread your original post, and the PM you sent, and realised that didn't sound like you at all. I can only assume some confusion somewhere along the line.

Rereading the first post (which though it does a pretty good job of including the fundamental facts doesn't quite answer all the questions) I realised my first reply suffered from confusing some of the FileAs with FileBs. FileA doesn't have a reference to FileB, the one it somehow calls (more details of the practicalities of this would be helpful), but FileB is the one with the reference to FileA, the original file with the updated data.

The important question here and now then is :
What are you referring to when you say a Reference?

Access References are actually library references that give information as to what objects and procedures are available from that library. An Access database can be referenced as a library as it does contain code that can be called. With this you may be able to call the .Requery of the form required in FileA, from FileB, but only because the instance of a class, when dealing with form classes, typically use the same name as the class itself. This may be worth a try.

If what you mean by Reference is actually a Form parameter passed to whatever procedure you originally called, then this too can give access to the form's code. Even more easily in fact. That would be simply Call FileAFormObject.Requery.

This would certainly have been easier to deal with had the clues contained in the code been available to look through. Please be very careful in future before deciding something you've been asked for isn't relevant.

[Stephen Parker]

123456789.