Lots and SQL backend
Phil Longstaff
plongstaff at rogers.com
Mon Sep 8 17:08:04 EDT 2008
Derek Atkins wrote:
> Phil,
>
> Phil Longstaff <plongstaff at rogers.com> writes:
>
>
>> I don't know enough about how lots are used in the system.
>>
>> There is a problem with the SQL backend when you unpost an invoice.
>> The problem is that the lot table is defined to disallow a null
>> value for the account. However, when you unpost an unpaid invoice,
>> the posting transaction is deleted, so all splits associated with
>> the lot are deleted. In gnc_lot_remove_split(), when the last split
>> is removed from the lot, the lot is removed from the account and
>> lot->account is set to NULL. The lot is then saved. This causes
>> the SQL UPDATE to fail because the account can't be NULL.
>>
>> I assume it would be OK to delete the lot at this point. Derek?
>> You know the business stuff best.
>>
>
> I think it might be safe to delete the lot IFF the lot really is
> empty. It might not be empty, because there might be a payment
> attached to it. So you can't just delete the lot when you unpost
> the invoice.
>
> However I think it would be safe to delete the lot if you check
> that the lot is empty first.
>
Well, the code for the function is:
*
void
**gnc_lot_remove_split* (GNCLot *lot, Split *split)
{
*if* (!lot || !split) *return*;
ENTER (*"(lot=%p, split=%p)"*, lot, split);
gnc_lot_begin_edit(lot);
qof_instance_set_dirty(QOF_INSTANCE(lot));
lot->splits = g_list_remove (lot->splits, split);
xaccSplitSetLot(split, NULL);
lot->is_closed = -1; //* force an is-closed computation */
/*
if* (NULL == lot->splits)
{
xaccAccountRemoveLot (lot->account, lot);
lot->account = NULL;
}
/ /gnc_lot_commit_edit(lot);
qof_event_gen (&lot->inst, QOF_EVENT_MODIFY, NULL);
}
Once lot->splits == NULL, there are no splits, so unless there is some
other way that the payment might be tied in, it would be safe to replace
"lot->account = NULL" with "qof_instance_set_destroying(lot, TRUE)".
Phil
More information about the gnucash-devel
mailing list