sql backend failure when deleting an account

[Conrad Canterford]

Matthew Vanecek wrote:

 > Anyhow, the above little change allows deletes (of transactions and
 > of accounts) to work correctly.  I think the sql backend would be
 > more-or-less OK if that were implemented.  Of course, I still need
 > to find the best way to get the objtype field, to correctly note the
 >  type of transaction being deleted.

OK, I should have spoken up earlier, but I'm a little preoccupied at the 
moment....

I'm not convinced of the wisdom of allowing actual deletes in the 
database version in the normal course of events. I accept it for a home 
user version, but for something potentially intended for business use, I 
would think that accountability (one of the key reasons for accountancy 
:-)) would require *not* actually deleting information.

I thought goonie did some stuff on making "voided" transactions using 
the reconcile flag. If I'm remembering things properly, this process 
should be used, not a real delete from the database. A similar approach 
should be developed for no-longer-current accounts.

The point is that you want to remove them from the "normal" view of 
things, but leave the records intact for historical and accountabilty 
tracing.

Having said all that, there is are cases where stuff really can be 
deleted (after a particular period of time, is the case that comes 
immediately to mind). I agree we must be able to do that, but I don't 
have an immediate solution in mind as to how it can be achieved. If this 
discussion continues into next week, I may be in a position to think 
about it more at that point.

-- 
Conrad Canterford  (conrad@mail.watersprite.com.au)
Water Sprite Pty Ltd   |  url - http://www.watersprite.com.au/
GPO Box 355,           |  - Australian Tour and Event Management (ATEM)
Canberra, ACT 2601     |  - Ticketing Division.
Mobile: +61 402 697054 |  - Catering Services Division.