Scott Steele Ricoh USA

Using a USB connected barcode scanner as an input device to assist with indexing documents within the Store Dialog process. In regards to this discussion, the field is a 12 digit serial number, defined as a keyword data type (allowing multiple values).

Scenario #1: If the DW Store Dialog process [web interface] is the only task (open window) that the workstation has open, when scanning the serial numbers with the barcode scanner, index values are properly scanned.

Scenario #2: If the workstation has several "open windows", i.e. Outlook, MSWord, RDP, Browser, Acrobat, … and the DW Store Dialog process [web instance], when scanning the serial numbers with the barcode scanner, results vary. Some values are correct while others are truncated (majority are incorrect). It is not until the other "open windows" are closed that the scan results are corrected.

Am not sure and having a hard time explaining why background applications affect the input results of the barcode scanner. Has anyone else experienced this phenomenon?

This is a medical equipment customer. I cannot send you MAG files. I have TeamViewer access to customer server if you would like to look at files.

Not sure what the MAG files have to do with the _PAGE table.

Please advise. Thank you

Is there a criteria in which records can be removed from the table?

OK. So if the documents that are being migrated have no reason for "one-click" indexing, can the "textshot" field be set to a value that does not consume so much space? OR Can the records be removed without loosing other functionality of the document?

In the process of migrating a Fortis customer to DocuWare (v6.12) using the "migration tool", approx. 1.5 million documents. I have noticed the database = dwsystem, table = dwtasks is rather large and does not seem to be reducing in size. It is currently 7.7 GB, with 10,602,091 records.

Why is this table so large? Will it eventually shrink over time or is this historical data that needs to be kept?

Please advise. Thank you

Within the file cabinet configuration, even if "Fulltext search" is disabled,

• would changing the "Indexed pages per file" from 100 to 1 be of any value to reduce the number of records in  _PAGE table?
• could I "Blacklist" Graphic files to reduce the number of records in _PAGE table? (reasoning, migrating TIFFs from Fortis)

Am in the process of migrating a current Fortis customer to DocuWare (v6.12) and am experiencing EXTREMELY large SQL database sizes in comparison to what the Fortis database size was.

Example, Fortis database size is 3.2 GB, current DocuWare database (dwdata) size is 17.5 GB (and am not done migrating).
Note: dwsystem is also 8.6 GB
Log files: dwdata size is 21.2 GB and dwsystem is 19.3 GB

Deeper look shows the extreme size is due to the _PAGE table for each file cabinet. Something to do with the textshot column, binary data?

I have been told that the _PAGE table will always create textshots for every document regardless of fulltext being enabled within the file cabinet. What is the textshot used for then if "fulltext search" is diabled within the file cabinet options?


 

Applied latest Hotfix Pack 2019-03-27

NON WORKING method

• User Settings : Viewer = "Open DocuWare Viewer with index dialog in new window"
• Store document with bogus entry for field = [Record Type]
• Open document (in new window)
• Update field = [Record Type] to another bogus value
• SAVE, NO error message, window with document and data closes, no change in data

Still a problem with this method.
 

Tested per your instructions. One method works, another does not.

WORKING method:

• User Settings : Viewer = "Always show DocuWare Viewer in same window"
• Store document with bogus entry for field = [Record Type]
• Via context menu, "Edit index entries"
• Update field = [Record Type] to another bogus value
• SAVE, error message = Value invalid, document cannot be saved

NON WORKING method

• User Settings : Viewer = "Open DocuWare Viewer with index dialog in new window"
• Store document with bogus entry for field = [Record Type]
• Open document (in new window)
• Update field = [Record Type] to another bogus value
• SAVE, NO error message, window with document and data closes, no change in data

Why? Shouldn't both methods work?

I made the following changes:

Made the database field [Record Type] = REQUIRED
STORE Dialog does not restrict the value of [Record Type], but does require a value. I entered "imported".
RESULT DIALOG restricts [Record Type] to select list, ("imported" IS NOT a valid entry per the select list) and the "The user can only use entries from the select list to set the field" is ENABLED.

When I edit the document and metadata, I changed another index value, but left the [Record Type] field = "imported", then selected SAVE. I was NOT prompted that [Record Type] was invalid.

What allows to SAVE the record with an invalid entry for [Record Type]? What makes DocuWare think "imported" is part of the select list?