I'm going to try to update this using moderator abilities to get in.
@amorosik -
Part 1: Let's talk Windows for a moment. It is a primary tenet of the Windows Operating System that tasks
must be independent of each other, derived from an old U.S. Government requirement for inter-process security. Microsoft implemented the requirement because if they did not, the military would have disqualified ALL Windows systems from sensitive government offices. I don't know about the OTHER services, but the U.S. Navy Reserve "Outlook Address Book" held over 50,000 listings. Multiply that by Active Navy and then Reserve & Active Army, Air Force, Marine Corps, Coast Guard, ... and then the cabinet level departments. Microsoft couldn't NOT provide the requirement given the size of that market. Though the standard in question has long since been modernized, the old "C2" requirement based on something called "The Orange Book" absolutely required that, in the absence of privileges,
no process could affect the state of another process directly without a pre-programmed interface for the purpose. My authority for that statement is 28 1/2 years of U.S Navy Reserve employment and yearly refreshers on security principles, plus the CompTIA "Security Plus" certification.
Part 2: Access runs under Windows as a non-privileged task and thus is protected and governed by the non-interference rule. Firebase, because it is not a part of Access, would of necessity run as a separate task from Access. Only the JET or ACE database engines are integrated to the Access environment. Firebase is not. Therefore without some defined interfaces, it would be ILLEGAL (and thus prevented) for Firebase to directly notify Access.
The way that Access talks to another Office component is that it launches the other utility and exercises the STDIN and STDOUT channels of the hosting process to communicate with the program. Those "other" components take on a life of their own and if Access dies while it has a partner process active, that partner doesn't die - but is now uncontrolled. So you usually have to kill it from the console.
Part 3: There would be one other possibility. If Firebase doesn't support ODBC but DOES provide a Component Object Model (COM) library to expose its various operations, it MIGHT be possible to interact with it intimately. Without either ODBC or COM interfaces, the answer is "no clean and easy interaction is possible."
Part 4: Let's consider your comments about communicating between Firebase and Access. Yes, Access absolutely and categorically CAN communicate via WinSock-related methods. The method to do this involves building a socket and setting up code to listen to that socket. The catch is that the code needs a supporting framework, and that USUALLY will be the class module of a form. When that form starts listening, if you want to be doing anything else you need to have another form open because Access executes all event-level (module-level) code SYNCHRONOUSLY. Each form has its own thread. A listener form is dead unless/until a message comes in. That listener form will do nothing else until the socket triggers something. (Emphasis: NO ASYNCHRONOUS I/O!!!) If you have a Firebase socket that connects to the Access socket (or vice versa) it would be possible to define a handshake between the two entities. Where it gets nasty is that Access is not designed to talk to anything other than JET/ACE engines unless using a recognized database linking protocol such as ODBC.
Let's say you do this via sockets, set up Firebase as the sender and set up an Access form as the listener. So.... you finally got a message to your listener? If the message contains a record, you could build a DAO.Recordset operation to do a table update, perhaps. But what you just did was re-invented the ODBC wheel. And of course, because of the synchronous nature of code in the Access program environment, you have to continue to re-prime the listener. Which means your sender has to be an active participant in the handshake. It can't send more than one record at a time, which means (gasp) polling, the very thing to which you objected.
Can Access do its part in this? Absolutely. Can Firebase do its part? Damned if I know. But your insistence on hammering at something that folks tried to explain to you shows your impatience and maybe also explains why the replies became so hostile.
