Incomplete Commit

[Seth_Yantiss]

Hello,

I have a scan queue that is getting two document types from Subscription Server.  The e-mail is stored as one document type and the attchement (usually just one) stored as another document type.  The documents go through an Image manipulation of convert to TIFF (which I actually don't want for the e-mail) and then an auto-rotate. 

Then since they are fully indexed, move to be auto committed.  Once committed, the attachment is supposed to enter workflow.  The attachment document type is the only one assigned to workflow.

The Commit is failing, I think it's at the add to workflow step.

I only have 1 copy for the DG settings.  The first workflow action for the attachment was to change the document type, but I moved that to a timer.  Since only one of the documents in the batch were being added to workflow, I tested adding both to workflow.

I'm not getting any errors in Diag Console.  And am stumpped...  any ideas on why a commit would fail?

Cheers,
Seth

[Steve_Reed]

You mentioned above that you looked in the diagnostic console for errors - but was this on the client or on the Application Server?  If you haven't checked a Diag Console log on the App Server, I'd suggest that as the next step.

[Seth_Yantiss]

I'm running the Thick Client and Diag Console on the same machine that is hosting the APP Server.   Is there some other error log or tool that I should look at?

Thanks,
Seth

[Steve_Reed]

Try a thick client verbose log.

[Seth_Yantiss]

So, I did that, but just have a bunch of SQL queries and APP Server connections without responses.

Here's a log snip from what I see at the attempt to commit:

Preparing:

>> 02/08/2013 11:27:41:387  [Thread:2244]

Update hsi.archivedqueue Set queuenum=?, queuename=?, batchname=?, status=?,
 tmpdiskgroupnum=?, tmplogicalplttrnum=?, diskgroupnum=?, logicalplatternum=?,
 usernum=?, datestarted=?, dateended=?, numberdocuments=?, archiveflags=?,
 bitmapnum=?, iconnum=?, lastusedplatter=?, totalpages=?, printeddate=?,
 totaldocuments=?, batchflags=?, registernum=? Where hsi.archivedqueue.batchnum
=  ?

>> 02/08/2013 11:27:41:387  [Thread:2244]

[DB Connection: 0x4251538]

Update hsi.archivedqueue Set queuenum=118, queuename='SS - Cancellations',
 batchname='2013-02-07 - MANAGER', status=4, tmpdiskgroupnum=109,
 tmplogicalplttrnum=5, diskgroupnum=109, logicalplatternum=5, usernum=2,
 datestarted=2013-02-07 21:21:40.0, dateended=2013-02-07 20:21:52.0,
 numberdocuments=2, archiveflags=0, bitmapnum=0, iconnum=0, lastusedplatter=0,
 totalpages=65536, printeddate=1964-01-01 00:00:00.0, totaldocuments=2,
 batchflags=0, registernum=197 Where hsi.archivedqueue.batchnum =  155147

>> 02/08/2013 11:27:41:403  [Thread:2244]

>> 02/08/2013 11:27:41:544  [Thread:2244]

Preparing:

>> 02/08/2013 11:27:41:544  [Thread:2244]

Select hsi.vbscripthooks.usergroupnum, hsi.vbscripthooks.seqnum,
 hsi.vbscripthooks.programlocation, hsi.vbscripthooks.keyvalue,
 hsi.vbscripthooks.keykeytype, hsi.vbscripthooks.vbscriptnum
From hsi.vbscripthooks
Order by hsi.vbscripthooks.keykeytype , hsi.vbscripthooks.seqnum

>> 02/08/2013 11:27:41:544  [Thread:2244]

[DB Connection: 0x4251538]

Select hsi.vbscripthooks.usergroupnum, hsi.vbscripthooks.seqnum,
 hsi.vbscripthooks.programlocation, hsi.vbscripthooks.keyvalue,
 hsi.vbscripthooks.keykeytype, hsi.vbscripthooks.vbscriptnum
From hsi.vbscripthooks
Order by hsi.vbscripthooks.keykeytype , hsi.vbscripthooks.seqnum

>> 02/08/2013 11:27:41:544  [Thread:2244]

[#6]

I had problems like this also. I solved it by turning off auto commit on the scan queue and scheduling the commit. Then rewrote the workflow so the first WF queue was a timer that moved it to a second queue that did the processing. Having an initial timer that does any kind of rules or actions,besides sending it to the next queue, seems to create problems.