-
Document linking
Linking a Document is not called a Relationship and it is Under File Cabinet
Select the Result Dialog you wish to add the link to it should open the configuration.At the bottom left Select MORE OPTIONS
Now Scroll Down is you dod not see any change......
Near the center Select the link Create New Relations
Name this Link
Selec the Item it is related to, in your example File Cabinet
Add the rules that would apply in your caseThen Save it,
-
Details
I think I need to see more specific information.
Date format Where? In Docuware? On the Document being added to the workflow...
Help me understand more.
-
Work around
I know this will add to the time it takes to do what you need but a work around we have found is to staple/clip the documents we need to delete then delete the one document....this adds a great deal of time to the process if you are doing all of your editing in Docuware.
-
You can add more threads to the local machine helps
Every following points have to be done directly on the Client:
The amount of paralell processing tasks are limited to 2 by default. Server-Clients enviroments with high performance are not using the full capacity. To higher the number of processing tasks please raise in the: "C:\Program Files (x86)\DocuWare\Desktop\DocuWare.DesktopService.exe.config" the following key: [...],add kwy="ConcurrencyMaximum" value="2"/> [...]
After changing the value, please restart the DocUWare Desktop Service. Note: These settings will affect DocuWare WebScan, Printer and Import. Particulary on so-called scan-workstations you can raise the value, for e.g. 6-8. Raise the values gradually and check the processor and memory on real working operations. I have a few set between 32 and 50 so jump by 5 or 10 to get the right number
If you have more than one scan-workstations, please don't raise the values too high because otherwise the server is too busy to handle it.
Notifications over DocuWare Desktop Tray-Icon can be disabled to lower the CPU load. You have more ways to do this. First option would be to disable it over the Control Panel\All Control Panel Items\Notification Area Icons.
You can also disbable it in the:"C:\Program Files (x86)\DocuWare\Desktop\DocuWare.Desktop.exe.config" over the following value: [...]
<add key="TrayNotificationLevel" value="Nothing"/>These changes takes affect after restarting the DocuWare Desktop (Application) Possible values for TrayNotificationLevel are: Nothing, Error, Warning, Info
-
You ARE DEAD ON....Smaller, easy to fix reusable parts, Thumbsup
Over the year, programming evolved from 1 block of code to many blocks of code. It made it easier to work with. Using the same ideas when working with Docuware can be very useful. MANY building blocks is not only easier to edit but it can be easier to update in the future and reuse in ajoining processes. Workflows feeding other workflows, filecabinets feeding other filecabinets I have one client with multiple databases for file cabinets making it easier to track down SQL issues and congestion ptroblems.
-
Fonts that read well......
Have you tried OCR-A, OCR A Extended, OCR-B from Seagull?
-
Encryption in place
I have a number of clients which are CJIS (Criminal Justice Information Service) compliant and practice encryption in place. You can do this commonly without impact to Docuware as the encryption normally does not effect performance or connectivity. The userse see everything in place as if it were just common storage. The idea is if someone attacked from outside the system or gained access to the actual hardware the physical data on the drives would be encrypted and unusable. If someone stole the hard drive the data would be worthless.
Also you have to worry about the data in SQl....you do not want to enrcypt SQL storage directly but you need proection. You do not want someone copying the entire database mdb files and be able to read them....Microsoft has an encryption in place tool for SQL. We have a number of users taking this approach and I have not seem any impact with MS SQL's implementation. Long sotry short is test it test it test it. I would guess that it will work but....some methods expecially those that rely on the clound may have serious vulnerablilties.....what if the cloud is not available etc...
Encryption in place is a good pracice for Goverment, Healthcare and personel.
A good practice for everyone to understand better because there is a day when a client will ask for it.
Craig
-
You can probably do it the way we used to do 4.5 to 6
When we upgraded 4.5 to 6 styel docuemnts we used an export/import method.
Build an export workflow to copy the records to an identical file cabinet then export them back to the old file cabinet...
The system converts the files when importing to the new file cabinet, Copying them back just moves them back into play.
It is slow but it is a work around we still use....converted a 4.5 just a few months ago....
-
You are correct import works very well....
Importing the douments using IMPORT is a XML only thing,
It is pretty easy to restructure the CSV file to meet the xml standard.
Here is an example...See if that helps.
http://www.commicrofilm.com/home/about/help/importingfilesusingthecontro...by the way the importer is very touchy about upper and lower case they have to match 100%
I had a client who was output the files in pdf as "name of file.PDF:
in the data stream they had the file name insert like this<InsertFile path='name of file.pdf'/>
Would not go in.....everything needs to match..and in the above example the single quotes are correct...
By the way if the client is creating the PDF can they PRINT them to the printer using eh control codes?
You can add a line at the top of the page and make the font SUPER small using the dwcontrol font and print the file straight to Docuware as well.An example fo that is here:
http://www.commicrofilm.com/home/about/help/usingdwcontrolfontwithdocuwa...I am slow on EMAIL but glad to help when I have time.
Craig
-
Phil is 100% correct
If this is something you did not try and do not know how it will effect the system or how to trouble shoot it if it does go badly I would not try it on a live system ever. The thing is buidling a new field to hold the data, deleting the old one then rebuilding the old field is a really common practice amoung many SQL programmers that know messing with LIVE data on a system can cause issues. Rememer slow is SMOOTh and SMOOTH is fast. The neat thing is you do not have to use Auto index to do it any more.....you can use the workflow to update the HEADER file off the database....so you could:
1: Copy the data from the table in question to another database....
2: Delete the field in question
3: UPDATE/APPLY everything....even logging out of configuration etc is a good idea.../
4: Log back in add the field back with the new size.
5: Copy the data you backed up into the new field. (users can see the data now but you are not backed up)
6: Build a restore that will OVER Write the XML with Database.....
7: Run it.....done....If you have a really big database or do not have autoindex this should work.