Reuben Cummings <reub...@gmail.com> writes:
>>>>> SELECT
>>>>> entries.invoice
>>>>>
>>>>> FROM entries
>>>>> LEFT OUTER JOIN invoices ON entries.invoice = invoices.guid
>>>>> WHERE invoices.guid IS NULL
>>>>> GROUP BY entries.invoice
>>>>
>>>> Do you really need the join here?
>>>
>>> Yes. Since the orphan entries are identical to the non-orphan entries,
>>> the only way to filter them out is to join on the invoices table and
>>> exclude all the entries that match. That leaves entries with
>>> non-matching invoices... the orphan entries.
>>
>> Really? Why can't you just do:
>>
>> SELECT ... FROM entries where entries.invoice IS NULL?
>
> Because entries.invoices isn't null. Even the orphan entries have an invoice
> guid. It just that these guids are not present in the invoices table.
Oh, so the issue is that there was an Invoice that was created in RAM
but never committed. I see. That could never happen through the GUI,
but the importer clearly bypasses the GUI. So the Entries have a
reference to a non-existing Invoice. Very Interesting.
Thanks for working through this with me.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warl...@mit.edu PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
