Since the no. of entry screens to be locked might increase with enhancement(s), the approach could be
1. On completion of all entries by all, say for a day.
2. When opening the report, check whether only one user has logged in. Close the report window, if there are more than one users.
3. Flag somewhere in the db, that the processing has started.
4. Check at the opening event of the 'tobe locked screens', whether this flag set in point 3. If set, quit the screen.
5. Create a report from the entered data.
6. Create / Modify required entries from the values arrived in the report. [ long process ]
7. Once completed, commit all data. Reset the flag set in point 3.
8. Ensure that no data entered for the processed period. Data entered will be for another date. Data cannot [should] not entered for the processed date.
If this works out, we need to find a way to count the no. of users logged in the database.
On Friday, 28 February, 2020, 11:35:48 am IST, Rob Sargent <robjsargent@xxxxxxxxx> wrote:
On 2/27/20 10:38 PM, rob stone wrote:
>
> If the menu is built from a table in your database, then when
> "Processing report" starts you could set a flag (boolean) against those
> items so that if anybody tried to log-in or access those items, you
> could simply display a message along the lines of "Processing report is
> running. Please try again later".
>
> When "Processing report" finishes, it just clears that flag.
>
> HTH,
> Rob
>
Conversely, the OP could be asking for a way to turn "process report" to
active state when no one is using the other features: each of them could
set a lock/counter I guess and when all counters are zero enable process
button. The notion of waiting for "all clear" from the app or the db
before running reports does seem odd though. Do certain actions from
the app leave the database in an inconsistent state and break the report
were it run at the same time?
