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?
Hi Heather
t_ka_header is in the impresario_cci database
Mark
Have you definitely changed to the impresario_cci database?
Caryl
Hi Heather,
The table is in the impresario_cci database so you have to make sure to change the db reference:
USE Impresario_cci
GO
Update T_KA_HEADER…
Thanks for pointing this out though. That solution looks like it needs a bit of an update for the current version of SQL.
-Gregg
From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Heather FailsSent: Monday, June 13, 2011 12:45 PMTo: Gregg StickneySubject: [Tessitura Technical Forum] Extraction stuck in counting?
This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!
That did the trick, thank you all very much!
Does anyone know what causes extractions to get stuck in the 'counting' status to begin with? I have run a number of extractions in the past few days and all are frozen in counting.
Thanks,
Chuck Buchanan
Chuck,
Are these extractions using any custom List Builder elements?
--Gawain
No.
One extraction was as simple as one segment with just a single performance date. No matter what the criteria, all extractions are getting stuck in the counting status.
I've seen this happen in the past on more of a one-time-only basis, but not with all extractions one after another.
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.