> Actually, I would think a row-level trigger would be more appropriate. > Not possible in 1.3 unless we also decide to just scrap that release and go straight to 2.0.
The reason is, a single check hits a surprising number of rows in one table in the codebase we have inherited. I expect this to change in 1.4, as it is on our todo list and is just something we haven't had a chance to address yet. Checks have a many<->many relationship with invoices and there is no authoritative place to store that data in a normalized fashion. Note that this may change in 1.4 because we are likely to have a database structure more condusive to db-controlled solutions. However, at the moment, there is no way to implement any row-level rules regarding check printing. However, this poses another problem which is why session-level rules may still be necessary. Suppose 2 people start a check printing process. They don't know eachother is doing it. The web app is stateless so we have no way of doing proper transaction processing across requests. Person 1 pulls a list of vendors that need to be paid and applies the payments. Person 2 pulls the same list of vendors and applies the same payments. Person 1 prints and posts the payments Person 2 tries to print and post the payments and gets an error. If person 2 had been informed of the possibility that person 1 was actually using the data at the beginning, less time/productivity would have been wasted. Best Wishes, Chris Travers ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
