Mark Massey Cornerstone Building Brands

I'm not sure if this is a technical problem or a configuration issue, so this may not be the correct forum. I modified the LongLivingProcessConfiguration.config file to restrict fulltext operations to after-hours, and I also increased the number of CPUs to be used. The time restriction doesn't appear to do anything and processing resumed right away using more CPU. Has anyone run into this?

Also, what is the difference between Task Type 0 and Task Type 2 described in KBA-36661? The description seems to descibe the same thing.

"taskType=0"= controls the heavy CPU operations for the creation of the text-shots for the documents.
"taskType=2" controls the CPU operations for Full-text Indexing process.


Thanks,

If IIX is already installed on Windows 2016, must the OS be upgraded to 2019 to install DocuWare v7.9? DocuWare Help states 2019 is a requirement for IIX as a local installation. This is IIX v1.

Has anyone seen this error?

This user has no rights for the instance (instance ID of workflow follows).

Only one user has reported this, and it seems to only happen occasionally for her. The flow continues to process after the error.

Has anyone tied scheduling a MSMQ bus reset on an on-prem installation? Is there a reason one could not schedule a Powershell script to do so? Something like:

Get-Service -DisplayName "DocuWare*" | Stop-Service
Stop-Service -Name "was" -Force
Get-MsmqQueue -QueueType Private -Name "dw-*" | Clear-MsmqQueue
Start-Service -Name "w3svc"
Get-Service -DisplayName "DocuWare*" | Start-Service

As far as I can tell, the DocuWare message bus admin program deletes the queues, and they are rebuilt when the service is restarted. I'm not sure how one would select a different adapter via Powershell, or if it would matter (see KBA-35787).

Thanks,
Mark Massey


 

Thanks, Guys. I'll ask the DBA to save this query. I know the auditors will want us to provide this data occasionally.
 

I could use that, too, Steve.

Is there a 'User Permissions' or 'User Group Membership' report available from the app or admin station? 

Thanks!
 

It appears you concentrated on exporting everything first and saving the data in a DB (FoxPro), then imported it all using that DB and creating any needed cabinets or fields on the fly. That's pretty slick. I don't think I'm going to want to do that 'create' step, but I'll definitely look into coding an import processor. It looks pretty straightforward to me. Might have time to try an exporter, also. 

Thansk, Mr. Kaufman. This may save us quite a bit of time.

Joe,
I'm already using the old-fashioned multi-threading. Lots of experience with that...

If you wrote code to import multiple doc types simultaneously, then you went all-out. Did it report how many files were imported? For us, single doc types per run are fine. I would like to see a snippet or two, if possible. The code examples look fairly straightforward. Is that the case? 


Thanks,
massey