Re: Transaction Oriented Architecture (TOA)

If your application's SQL was already referencing the account table it will need to be modified to reference the view instead--or you'll have to rename the account table and replace it with a view--which is certain to mess up other account table dependents.

Additionally, there's no transaction history on SELECT statements (unless you wanted to enable security auditing.. but that's nasty). How do you make sure the requesting user has permission to see the view? How do you record their query? How do you make sure they only see accounts their allowed to see? Those features aren't present in views 'cause views don't have parameters (like user ID etc--unless you've added application user IDs to the database).

In our system's we'd have something like p_account(@sessionKey, @accountKey). The procedure would be able to verify permissions through the sessionKey (find the user, which party they belong to, which accounts belong to them, and if they have READ access), can record the transaction (sessionKey, transaction type, accountNumber), AND bury its implementation behind its interface (procedure name and parameters) so that changes to the account table, security, or transaction logging won't affect application code.

Implementing our system with a TOA/TOP design has afforded us unusual responsiveness to fixes and enhancements--many able to wind their way through development, QA, and into production within hours of the request--with minimal changes to applications. The fewer changes we make the faster and more confidently we can move to production.

--
Visit <http://blogs.instreamfinancial.com/anything.php> to read my rants on technology and the finance industry.
.

Relevant Pages

  • Re: New Method for Authenticated Public Key Exchange without Digital Certificates
    ... have the account disabled. ... then the next time you do a financial transaction ... ... eventually arrives at your financial institution ... ... in order to do credit card transactions, the merchant has to ...
    (sci.crypt)
  • Re: ComboBox Problem... Please, help me out!
    ... and tblTransDtl (transaction detail). ... You also have tables for SheetRegister and Account. ... Every sheet belongs to an only single ...
    (microsoft.public.access.formscoding)
  • Re: Query for Subform - G/L Account Transactions (Access XP)
    ... GLID COUNTER NOT NULL, -- a Counter is an AutoNumber ... xact_date DATETIME NOT NULL, -- transaction date ... Allow the user to select the description, reference, and transaction ... account in my chart of accounts. ...
    (microsoft.public.access.queries)
  • Re: Factories and lazy objects
    ... >>rules and policies for instantiation of the object and its ... > table, get the Account from the MainFrameConnection object, and pass it to ... > sheild the Account from the mainframe because there are planned upgrades to ... >>I have a hard time imagining a business environment where Transaction ...
    (comp.object)
  • Re: Query for Subform - G/L Account Transactions (Access XP)
    ... GLID COUNTER NOT NULL, -- a Counter is an AutoNumber ... xact_date DATETIME NOT NULL, -- transaction date ... Allow the user to select the description, reference, and transaction ... This form has several tabs (details, accounting rules, notes, etc) that are all tied together by the account number. ...
    (microsoft.public.access.queries)