• 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.

  • CLEAN uninstall

    I have been having an issue with Docuware 6.7 at the office.  I suspect it was from upgrading from previous versions. 

    In the interest in not wasting time trouble shooting the issues I decide to uninstall and reinstall with a whole new SQL etc

    Administration works, the thick client works but the web is blank when asking for \platform and I get a 404 page not found error otherwise...

    I need to know how to cleanly uninstall Docuware.....I want t make a CLEAN install. 

    Craig