...

Find transactions that have been processed by the first half of the daemons ie are queued in the Mantiki Temporary tables for writing to the SQL Server Dream Extractor database but not reached a 'done' state - this may be due to errors.

select 'process_extract_dream_shipment', id, extract_customer_number, extract_shipment_created_on as created_on, extract_shipment_reference_number, record_status, record_status_comment from process_extract_dream_shipment where record_status != 'done'
UNION
select 'process_extract_dream_credit', id, extract_customer_number, extract_refund_created_on as created_on, extract_credit_reference_number, record_status, record_status_comment from process_extract_dream_credit where record_status != 'done'
UNION
select 'process_extract_dream_wbpayment_customer', id, extract_customer_number, extract_created_on as created_on, extract_payment_reference_number, record_status, record_status_comment from process_extract_dream_wbpayment_customer where record_status != 'done'
UNION
select 'process_extract_dream_customer_number,wbrefund_customer', id, extract_customer_number, extract_created_on as created_on, extract_payment_reference_number, record_status, record_status_comment from process_extract_dream_wbrefund_customer where record_status != 'done'
UNION
select 'process_extract_dream_account_adjustment', id, extract_customer_number, extract_date as created_on, extract_account_type, record_status, record_status_comment from process_extract_dream_account_adjustment where record_status != 'done'
ORDER BY created_on DESC;

If you find your error in the above and the record_status_comment mentions a JDBC connectivity issue, then what you have is explained below - but basically Mantiki's failed to talk to the Preston database.  If you're within two or three days of the error happening then you can reset the record_status to NEW and the record will be found by the daemon and processed.   Find the id in the temporary table and make a query to update the rows.
The SQL will look like this: 
update
the table (will be one of process_extract_dream_shipment or process_extract_dream_credit or process_extract_dream_wbpayment_customer or process_extract_dream_wbrefund_customer or process_extract_dream_account_adjustment)
set record_status = 'NEW' where id in (             the id/s in the table           );

The transaction is marked as processed and I can see it in the temporary tables in Mantiki but it is not in Dream Extractor.  What's the problem?

...

The Dream Extractor daemons are a series of 2 part daemons.  First a transaction is copied into a temporary table within Mantiki.  From there it is accessed a second time upon which it is written to the Dream Extractor tables.  On a very rare occasion, the entry may be copied to the temporary tables but access may fail when attempting to write to the Dream Extractor table.  Because there is only one trigger for both actions, this results in the transaction being marked as processed when it has not been successfully transferred to the Dream Extractor tables.  It's unfortunate that this is a weakness of the methodology used with these paired daemons.  At this time, the solution is that Finance remedies these transactions manually and they always appear to spot them themselves but they will ask for an investigation when one occurs to ensure that there is no other problem with the transaction.

In the logs/rundeck, such a failure will look like this:

...

The transaction is marked as processed and I can see it in the temporary tables in Mantiki but it is not in Dream Extractor.  What's the problem?

...