I found this knowledge base answer to fixing a stuck extraction....
If an extraction is stuck in Editing, Counting or Scheduled status and you are sure that the extraction's status should be Open, the suggestion below should allow you to reset the status of the extraction to be Open. 1) Locate the extraction number that is stuck by noting the value in the "Extr No" column in Extractions. 2) Open a Query window in Enterprise Manager and switch to the impresario_cci database. 3) Issue the following statement, replacing ### with the extraction_no to be reset: Update t_ka_header set status = 'O' where ka_no = ### (If there are multiple extractions that need to be reset, note all of the extraction numbers and issue the following statement, replacing the # signs with these extraction numbers): Update t_ka_header set status = 'O' where ka_no in (#, ##, ###) You may want to try this in your test environment first to make sure you update the approriate extractions. Once everything appears to be in order, replicate this procedure in the live system."
Yet when I queried select * from t_ka_header where ka_no = 1512 I got "Msg 208, Level 16, State 1, Line 1Invalid object name 't_ka_header'".
I then searched the tables and found only 't_ka_response'. Has the naming convention of this table changed? Am I mentally challenged and or not had enough caffeine today?
My guess would be that something is wrong with your SQL Server Agent, most likely it’s stopped. Have IT take a look, and if they can’t figure it out, you should open a help ticket.
Kevin Sheehan
Senior Technical Writer & Consultant
Tessitura Network
+1 888 643 5778 x 329
ksheehan@tessituranetwork.com
Thanks, Kevin. It's back to normal now!
This maybe slightly off topic but here goes.
We are in a situation where using constituencies in an extract segment can take up to 90 minutes to process. We have tried using both "In" and "Has" but this doesn't seen to make any difference. The same criteria when used in List Manager takes a few seconds to complete - it's only when this is used in an extraction that we come across any issue. We use the "Search Household" check box. there are 381183 entries in the TX_CONST_CUST table.
Does anyone have any ideas on what causes this?
Hi Martin
I've just been working on our big extraction for the single tix DM.
It involves a few segments based on constituencies (5 of 30), with 'search HH' ticked , and they haven't been taking particularly long times to run. They don't return huge numbers (about 2,000 in all), but obviously they're pulling from the same TX_CONST_CUST . Generate Counts was taking only 3-4 minutes to run on each iteration. Those constituency-based segments were taking a second or less each
They look like this:
--------------------------------------------------------------
Select Distinct a.customer_no
From V_CUSTOMER_WITH_PRIMARY_GROUP a (Nolock)
JOIN vxs_const_cust e (Nolock) ON e.customer_no = a.expanded_customer_no
Where 1 = 1
AND e.constituency in (25,32,33,251,249,252,250)
------------------------------------------------------------------------------------
So your results are a bit of a puzzle. Not very helpful, I suppose.
(In case others are puzzled by the specificity, I'm working in the same (consortium) database as Martin, so I would expect our results to be similar.)
Ken
It's puzzling indeed. The SQL of the list is:
Select Distinct a.expanded_customer_no
Where IsNull(a.inactive, 1) = 1
AND e.constituency in (219,218)
In two Extractions run today, that particular segment took approx 100 minutes to process
Hi Martin,
Have you tried putting the constituency criteria in a separate list and importing that into the segment? It looks like this is what Ken has done with his extraction.
I wonder if the ISNULL(a.inactive,1) = 1 is causing the problem. You could also try a manual edit and change that predicate to a.inactive = 1 (i.e. get rid of the ISNULL function).
Patrick.