Nathan French

Oh thank you!  

I named them differently to keep track of what I was seeing.  
Thought I was being clever.

I've created a 32-bit ODBC connection to a SQL Server 2000 database.  I have done this because DocuWare's SQL driver can't apparently connect to the ancient SQL Server 2000 directly.  I can connect to this ODBC source and authenticate using the ODBC driver in DocuWare Administration. 

In Select Lists, the source is available to choose but I cannot see any tables or views when I select it.  It's an empty dropdown.
In Workflow Designer, the source is again available, but choosing it gives the error "The specified DSN contains an architecture mismatch between the Driver and Application"  

I tried also presenting it as a 64-bit ODBC connection, but DocuWare cannot see that one at all.  It must be 32-bit ODBC.  So what is this about the architecture mismatch?

Can someone please advise what I'm missing?
 
Thanks much,
--Nate

EDIT:  I am using:
DocuWare 7.1 On-Premise
Windows Server 2016 1607 (DocuWare Server)
ODBC Data Source Administrator 32-bit
SQL Native Client 10.0 ODBC driver
ODBC Connection to SQL Server 2000
(DocuWare databases themselves are hosted on SQL Server 2014)

I see the current version 7.1 System Requirements document (link above from Tobias).  But I cannot find the corresponding information for 7.0.  The closest I'm finding is this tiny document:

Release Information > What's New in DocuWare Version 7 > Additional New Features and Usability Improvements in Version 7 > Configure and manage DocuWare > Changed System Requirements

Then, when 7.2 comes out, the document for 7.1 will be updated for 7.2. 
Then, the full list of requirements for both 7.0 and 7.1 will not be available.

I suggest this current version System Requirements document be copied over to live with its little brother Changed System Requirements prior to being updated for the next release.  Or they can be combined.

Thanks,
--Nate

EDIT: The document for 7.1, Changed System Requirements and Technical Release Notes, is located in a different position.  I suggest the position within the version's What's New folder should be the same for each version.

I'm noticing in cloud 7.1 systems that the data file used in a file connection can be locked somehow, and therefore cannot be updated.  Here's a transcript of an FTP session (in FileZilla) to the data directory.  The destination directory already contains "File_Connection_1.csv" which now needs to be updated with new information.  (Actual path names are redacted - "unique_directory_characters" replaces the actual string of characters for this cloud system.)
 

Status:      Starting upload of /path/to/document/File_Connection_1.csv
Command:   CWD /unique_directory_characters/data
Response:  250 OK. Current directory is /unique_directory_characters/data
Command:   TYPE I
Response:  200 TYPE is now 8-bit binary
Command:   PASV
Response:  227 Entering Passive Mode (40,122,29,90,157,205)
Command:   STOR File_Connection_1.csv
Response:  553 Can't open that file: Device or resource busy
Error:        Critical file transfer error

I think I locked this file when I was double-checking the columns for the file connection in the Administration tool, but the lock is still in place for quite a long time, it's been more than 4 hours now.  How can I get this lock to be released?  

The only alternative seems to be create a new autoindex job pointing to a new file connection using a renamed copy of this updated file.  I have done this as a workaround in the systems where this is happening, so there is no currently open or waiting issue.

Two questions:
- Is this the expected behavior?
- How long is this file lock supposed to exist?

Thanks,
Nate

This issue was already solved.  I only posted so others can find what I could not find when searching for this.

We encountered an odd workflow glitch on upgrading a system from 6.12 to 7.1, so I want to contribute the solution to this forum.

Accessing dates in Assign Data activities was causing a fault in workflow: "Object reference not set to an instance of an object."  The solution was in the calendar settings in the DocuWare Administration > OrganizationName > General.  

In this case, all days were found to be deselected, and start / end times were both 00:00:00.  Setting start/end to 00:00:00 / 11:59:59 and selecting some work days resolved this issue.  Dates could then successfully be assigned in workflow activities. 

No new workflow version needed to be created for this to begin functioning.

I have the same question.  The cutoff limit applies in this case to a file connection.

Perfect!

'nslookup' also works and I don't have to cancel the pings.  

Thank you Josef!

Steve, I've had pretty consistent luck with this method:

- Open Services
- Go to the properties for DocuWare Desktop Service
- Change Start Up type to "Automatic (Delayed Start)"

Although it will take a few extra minutes for the service to get up and running, it allows the service to start reliably after reboot in the handful of cases where I have made this change. 

Recently I was working with a Cloud customer who was experiencing some timeouts and general lack of responsiveness in their workflow.  Checking the status site http://status.docuware.cloud/ I could see that one of the US 7.0 columns had a known issue in Workflow. 

However, I couldn't be sure if that particular customer's organization was in US0 or US1.  Is there a way to discover which column on this chart a Cloud organization belongs to?

Thanks,
--Nate