UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Full Access Desktop Functionality In Awa's, Powerapps And Flow., Access 2013 Web App    
 
   
RobKoelmans
post Aug 4 2017, 05:33 AM
Post#1



Posts: 434
Joined: 25-November 14
From: Groningen, Netherlands


It finally dawned to me we always ran an instance of Access from within MS-Word in the nineties (and within Access itself btw). This is still possible by the interop library in C#. https://stackoverflow.com/questions/1039770...h-users-session

We run a get-URL in the AWA iFrame control that invokes any DoCmd's that we choose. This way we have total desktop query/macro/VBA-functionality available to Access Web App endusers. The AWA-developer only has to upload the desktop application into a shared folder of his organization in our hosting platform.

We have some dynamic linking of MDB's to SQL-server databases somewhere. Until we have that available again, the desktop application will have to have fixed linked tables from one or more AWA's. To maintain that, we're going to make Remote Desktop Clients available (on SPLA tariff) in which you can maintain your desktop app.

We're working on a swagger definition file that makes an access desktop application available for PowerApps and Flow as well. It's already possible to run any AWA-datamacro from PowerApps and Flow through the SQL-connector in Flow.
Kind regards,
Rob
Go to the top of the page
 
GroverParkGeorge
post Aug 4 2017, 06:44 AM
Post#2


UA Admin
Posts: 31,216
Joined: 20-June 02
From: Newcastle, WA


This is fascinating, Rob.

--------------------
Go to the top of the page
 
RobKoelmans
post Aug 4 2017, 08:19 AM
Post#3



Posts: 434
Joined: 25-November 14
From: Groningen, Netherlands


Thanks George,
We also got our SignalR chatservice to accept virtual chatroom members now. A virtual member is related to an AWA-database. Incoming chatmessages are pushed by the virtual member onto a table in its related AWA-database. The virtual member looks for a response message from the AWA OnCreate trigger and performs that. That message type can be a reply contribution to the same or another chatroom, so the AWA OnCreate trigger checks whether its own message is coming in again on each message. From inside, an AWA can invoke retrieval by the virtual member of a request message it placed on its response table (as always, by placing a Get-URL in its iFrame-control). The first appliance is going to be keeping data of more AWA databases synchronized, but different users each having only data that is concerned to them in their personal AWA instances will even be more interesting as deployment model. We already can synchronize an empty instance of an AWA by a (time-stamped) synchronize request after subscribing to a chatroom.

It's very thrilling when you subscribe to a chatroom and see all messaging between AWA's going by. Now all we have to do is to create traffic of messages that are cascadingly encrypted by successive AWA-nodes and we have sort of a basic engine for blockchain implementations. Furthermore, we can now create chatroom-bots now by addressing a virtual member in a chat.

Another really nice thing is that C# database projects create stored procedures and triggers in AWA's and remove them again automatically after usage. So we may be able to integrate LinqToSQL-projects without corrupting AWA-management on SQL-Databases. But the Access Desktop Create/Modify/Delete-queries are already much more efficient than the ForEach iterations in AWA DataMacros. We can go into the hundreds of millions of records now.
Kind regards,
Rob
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    14th December 2017 - 11:33 PM