[AccessD] Lookup Tables Implementation

James Button jamesbutton at blueyonder.co.uk
Mon Jan 31 10:29:39 CST 2022


OK, I may have not got what you were asking - 

But - 

The location of the 'App control data" surely depends on where that data is used

I suspect mostly within FE code.
With a small amount being used within queries - and those queries surely being
generated in the FE.

However - there is the consideration of 'secure keys' used to access data that
will be passed to the FE.
In those cases the "key data"  such as the userid that has been checked  against
the logon id, and the list of who is allowed what access to data should, for
'security'  be kept where no action on the FE device can get at, and change
those key values -

As in - startup FE gets ID of the accessor, and verifies that using password and
other checking  - so is allowed to update - say staff payroll - hours worked
details.
Do you want them to be able to modify that so they can also set the hourly rate
to that of the  legal staff, or the overpaid IT consultant?
Or reduce the contractor's rate to that of the 18 year old "proby" office
junior.

My view - 
The storage location of data entries is really a case of security first, and
then - maybe speed.
Populating the combo boxes - well what is confidential and needs to be protected
- BE 
with non-confidential stuff being on the FE, maybe as a FE install setting,
or a download once on first use
with a 'dirty' marker managed by the App,  and/or the user interface to get it
refreshed. 
As in for reports  - maybe load an Excel workbook  for what-if analysis on the
FE
BUT - that allows the FE user to copy the data to a USB stick !

Also  within 'security' comes recording logs of updates and who accessed what.

Back in them (old) days, with unreliable comms I favoured updates being the BE
actioning update requests passed from the FE to the BE using files (or queues),
 with the FE  having an async processes waiting on a trigger set by the BE.
As in setting a trigger marker indicating the update had been done - maybe a
file created on a BE folder that the FE only had read access to.

That being to deal with unreliable tech - such as a user's session disappearing
- definitely do not want the database to be locked by a FE process.
                          


-----Original Message-----
From: AccessD
<accessd-bounces+jamesbutton=blueyonder.co.uk at databaseadvisors.com> On Behalf Of
Arthur Fuller
Sent: Monday, January 31, 2022 3:25 PM
To: Access Developers discussion and problem solving
<accessd at databaseadvisors.com>
Cc: James Button <jamesbutton at blueyonder.co.uk>
Subject: Re: [AccessD] Lookup Tables Implementation

We are all agreed on lookup tables v. Value Lists. But now I have another
question. My habit has been, over the years, to declare the data source in
the BE not the FE. In cases where a Query is used, that means the query is
stored in the BE rather than the FE. The advantage is that every form or
report created "inherits" this information, and automatically creates combo
boxes etc. for me.
Opinions about this practice?

On Mon, Jan 31, 2022 at 4:24 AM James Button via AccessD <
accessd at databaseadvisors.com> wrote:

> Back in the (old) days when I was BD'ing
> I would have a table of control info for an app - still do similar for
> Excel
> apps
> Several more columns than were needed for the data  so I could include a
> key of
> 'data usage'  and  depending on the data type stickit in an appropriate
> column
> Means that an app could easily be conditioned for individual users - with a
> record of their own action/options as to the App processing
> Also - access to that set of data could be  limited  via their windows
> login
> and the user data  'added to the department, and corporate logo etc.
> details
> for things that were sold on.
>
> JimB
> 



More information about the AccessD mailing list