Re: (not entirely...) OT: OPINION... chicken entrails, runic stones, and crystal balls... WAS CoBOL moved to OO

From: Doug Scott (dwscott_at_ieee.org)
Date: 01/03/04 

Date: Sat, 03 Jan 2004 21:30:05 GMT

Pierra,

> 1. If all the payroll processing is done dynamically/real time - how do
> you balance it?

Well you need to timestamp every transaction (to within a microsecond) and
then any processing must declare the time limits within its processing
boundary. It's theoretically possible, but we never implemented it. And the
timestamp must be related to the time of data entry, not the logical date
of the transaction (i.e. Corrections to earlier incorrect entries may well
not be processed because the "batch" run had started, even though the
system was aware of them).

> During the last conversion project I worked on, the end users were
> furious that they now would have to remember to initiate their periodic
> processes because the traditional batch operator was gone.

I should bloody well think so. It's not difficult to write a small
scheduler such as provided by any diary alarm system. Your designers didn't
do a complete job, that's all.

> Just because the tools change, does not mean the the functions go away.

Well, you've just shown that designers can design functionality out of the
system, forcing it back onto the users. Sad times. 

---
Doug
dwscott@ieee.org

Relevant Pages

  • Re: Concurrency Help
    ... All you need to do to implement it is to add a TimeStamp ... only client/user X has rights ... Another approach is to use pessimistic locks. ... Then the operation is wrapped inside a transaction. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Combine Secure 3DES Encryption with ability to count occurence of known plaintext - how to accom
    ... >The problem I have is the limited capabilities of the HSP. ... When I have a transaction, ... add, timestamp) to set B. ... Ecould be a deterministic encryption algorithm, or it ...
    (sci.crypt)
  • Re: Beware: Timestamps are not contained inside Transactions!!
    ... table might be to get it within the scope of a trigger, ... create table stamp ... > Our databases have tables that use a Timestamp column for row-level> concurrency checking. ... > The steps we used to recreate/test this scenario follows:> 1 - A transaction is opened and a new record is inserted into table A> 2 - On a separate connection, another transaction is opened and a new record> is inserted into table B ...
    (microsoft.public.sqlserver.server)
  • Re: Beware: Timestamps are not contained inside Transactions!!
    ... table might be to get it within the scope of a trigger, ... create table stamp ... > Our databases have tables that use a Timestamp column for row-level> concurrency checking. ... > The steps we used to recreate/test this scenario follows:> 1 - A transaction is opened and a new record is inserted into table A> 2 - On a separate connection, another transaction is opened and a new record> is inserted into table B ...
    (microsoft.public.sqlserver.programming)