[AccessD] Is it over for desktop apps?

[Paul Wolstenholme]

  Hi,

My users have Access installed on their computers and they run a batch file
to open a local copy of the Access FE database.  The batch file first
checks whether the computer - user combination has the latest front end, if
necessary copying it from the company LAN and creating a file to flag that
the new FE update was received.  When a new master front end becomes
available, the flag files are deleted from the network folder to signify
that no user has copied the latest version.

The back end is SQL Server, also on the company LAN.  Some remote users
need to use VPN to access the database.  That can be slow unless the
database is optimised for that.

The database includes scheduling and recipes for use in a factory
production process as well as data monitored from the process.  Other
systems control the factory from SQL Server data and record factory data to
the database.

Unlike the rest of the system, Access falls short of being industrial
software, as does anything involving 'the cloud'.  Microsoft updates
has in the past delivered new bugs to Access capable of crippling operation
overnight.  Microsoft SQL Server and other products I use do not experience
the same fate.

For anything involving factory production, reliability is paramount and a
local server wins out over the cloud on that score.

We are now seriously asking who can support this factory into the future.
My colleague has retired.  There was a particular week during my recent
covid experience that made the great resignation look like a good idea
for me now.  Is Access even the right tool to persist with in this case?

Paul Wolstenholme

On Mon, 12 Sept 2022 at 12:42, Stuart McLachlan <stuart at lexacorp.com.pg>
wrote:

> On 11 Sep 2022 at 20:03, Arthur Fuller wrote:
>
> > Hey Rocky,
> >
> > Thanks for your input. But I also need a bit of the nuts-and-bolts.
> > How do you deploy said apps? BE on a server, presumably, but what
> > about the FEs? Do you give them a link from which to download the
> > current virginm or physically copy said FEs to the clients's boxes, or
> > something like that?
>
> I use one of two methods  with a local FE and a remote BE,  which one to
> use is dependent
> on the network in question and the application. Both use a small "stub"
> which can be a
> Batch file or a small executable in the executable directory with a
> desktop link. Users are
> trained to always use the desktop link to open the application
>
> 1.  The stub  always get the latest FE and then opens it (works fine for a
> reasoable sized
> executable and a fast network)
>
> Here's the complete PB source for one such executable:
> #COMPILE EXE
> DECLARE FUNCTION ShellExecute LIB "SHELL32.DLL" ALIAS "ShellExecuteW" _
>    (BYVAL Hwnd AS LONG, BYVAL lpOperation AS STRING, _
>    BYVAL lpFile AS STRING, BYVAL lpParameters AS STRING, BYVAL lpDirectory
> _
>    AS STRING, BYVAL nShowCmd AS LONG) AS LONG
>
> FUNCTION PBMAIN () AS LONG
> LOCAL wstrMaster AS WSTRING
> LOCAL wstrFile AS WSTRING
> wstrMaster = "\\MISServer\MISMaster\MMS.accdb"
> wstrFile = "C:\MIS\MMS.accdb"
> FILECOPY wstrMaster, wstrFile
> ShellExecute 0, "Open", strFile, "", "", %SW_NORMAL
> END FUNCTION
>
> 2.  The stub checks the  version of the local FE and the one on the server
> and downloads it
> if it is newer (better on a slow network or with a large FE.).
> That uses either some form of version identifier in the FE which the stub
> accesses or a
> simple one line control file on the server  and an ini file or Registry
> value on the workstation
> which  holds the current version number.
>
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>