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?
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:
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.
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.
- Is this the expected behavior?
- How long is this file lock supposed to exist?
This issue was already solved. I only posted so others can find what I could not find when searching for this.