• RE: Canon scanner slowdowns after Windows Feature Update

    Shawn,

    We discovered that even in the Canon software scans would slow down.

    So, we bought a Fujitsu 7160, and it is very speedy and does a nice job. No slowdowns so far for anyone with Feature Update 2004.

    Thanks,

    Joe Kaufman

  • RE: Setting Document Name view REST api

    Not a problem, glad it worked! Interesting scenario, and it is good to know one can force the filename to be the document name in that way!

    Thanks,
    Joe Kaufman
  • Canon scanner slowdowns after Windows Feature Update

    Hello,

    Shot in the dark here, but has anyone else noticed slowdowns in scanning after a scanning workstation is updated to use Windows Feature Update 2004? We have one person here who, after running the update, has scanning operations take a second or two per page where the scanning used to be a continuous stream. When the 2004 feature update is uninstalled, scanning resumes full speed.

    Canon has not been helpful thus far, so it would seem they have not had many (or any) people report a slowdown, but I thought I would try posting here. We are running DocuWare 6.11 on-premise and use Canon scanners such as the DR-6010C.

    Thanks,
    Joe Kaufman

    P.S. As a bonus question, what brand of scanner do other folks use? Anything else in the Canon price point that works as well with DocuWare? Any gotchas (or brands) to avoid in anyone else's experience?
  • RE: Setting Document Name view REST api

    Stephen,

    I believe the name is determined by whichever database field (index) is given the "Document Name" attribute when designing the file cabinet. There can be only one "Document Name" field designated, and when that index is filled in, it becomes the document name.

    What are you placing in the field designated as Document Name? If you set that index (via the API or the web client), does the name then display as you would hope?

    Thanks,
    Joe Kaufman
  • RE: REST API - Logon Issue

    Adriano.

    I am not sure what you have all tried, but it is very possible to login to DocuWare with basic authentication. Check out this post:

    https://support.docuware.com/de-DE/forums/questions-about-usage-and-configuration/cd2c7857-8f41-e911-a967-000d3ab3fe8a

    There are details on how I use Foxpro to access DocuWare (on-premise, version 6.11). 

    Long story short, via Postman, if you do a POST with the URL:

    http://<server>/DocuWare/Platform/Account/Logon?Organization=<org name>&Username=<username>&Password=<password>

    you should see XML representing various DocuWare links -- it means you are authenticated. If you do this POST with some sort of persistent connection/request object (such as MSXML2.ServerXMLHTTP or MSXML2.XMLHTTP on Windows), you can then do additional GETs to access the various API functions.

    Hope this helps!

    Thanks,
    Joe Kaufman

     
  • RE: What date is displayed in the viewer?

    Steve,

    That's a really good question.

    I could not find that date anywhere in the DocuWare database. I checked the base dwdata table, the related _SECT table, and the related _PAGE table. Didn't find anything that matched.

    So, I found the root document as stored in the file system on the DocuWare server. DocuWare stores the actual document in a defined hierarchy, and the file will always have an XML file beside it. In the XML file is a modification time that matches, and it matches the last modification time on the file itself. Since the viewer obviously pulls the document in from it's file-based location, it must get the information from the document as it does so, and displays the last time the document itself was modified/created when it was just a regular old file on disk.

    I am not sure if that date resides anywhere else, and I am not sure if it comes back in the document information class when using the Platform SDK. That means I am not at all sure as to how you could easily pull that date on your own. Hopefully someone more in the know responds with a more thorough answer...

    Thanks,
    Joe Kaufman
  • RE: read from table column with SDK

    Jon,

    First off, do you have access to the underlying database? It is always easier to query the index data directly if that is the case.

    If you don;t have access to the database, then you need to get back document information one of two ways: 1) Pull down all documents in a file cabinet, or 2) Execute a query via the SDK to get a list of documents back. When you get a "Document" object back it isn't the actual document, but the record representing the indexes for the document (which is what you need).

    This describes how you get all documents from a document tray or file cabinet:

    https://developer.docuware.com/dotNet_CodeExamples/f9a6a984-57a9-42e9-8d26-1dd35611cf47.html

    and this explains how to execute a query:

    https://developer.docuware.com/dotNet_CodeExamples/b8b6ddf4-fee5-4b5c-84cc-046895c8aa5a.html

    Note that the data you get back from this is not as easy to parse as, say, a relational database table. But you can parse the returned documents using loops and things like LINQ to pluck out the information you need.

    Like I said, accessing the data directly is much more straightforward, so if that is an option, forego the SDK and hit the table directly. Just don;t do any modifications via that methodology.

    Thanks,
    Joe Kaufman
  • RE: C# Connection to REST API

    Vural,

    Glad to hear it! It was just a lucky guess on my part, as all the versions of .NET make my head hurt...

    Thanks,
    Joe Kaufman
  • RE: C# Connection to REST API

    Vural,

    The code for establishing a connection looks correct, but the error is not really related to that, I don't think. Something is going wrong when a certain assembly tries to get loaded.

    It is sort of a new version of "DLL Hell", and it sometimes relates to packages not being installed correctly (or versions being off). Assembly configuration is still a chore sometimes in the .NET world, but I do not know why you would be having versioning issues if you installed the latest DocuWare packages from NuGet.

    I think you may have a conflict with .NET Core vs. .NET Framework. What sort of application are you trying to code? That is, what is the project type? I assume you are using Visual Studio Code and not the full-blown (paid) version of Visual Studio? Here are a few links I found that talks about issues with the ConfigurationManager:

    https://github.com/pusher/pusher-websocket-dotnet/issues/34

    https://stackoverflow.com/questions/46360716/cant-use-system-configuration-configuration-manager-in-a-net-standard2-0-libra/50937932

    https://stackoverflow.com/questions/47098698/how-to-use-net-framework-from-net-core

    As you can see, StackOverflow is your friend.  *smile*  I am betting this is just a configuration/reference issue related to the type of application you are building. If you can develop a .NET Framework application using Windows Forms I know the stuff works, as that is what we use. I have not tried any DocuWare code as part of an ASP.NET or .NET Core project.

    Good luck!
    ​​​​​​​
    Joe Kaufman
  • RE: C# Connection to REST API

    Vural,

    Not sure if it is allowable for your project, but have you tried using the very nice DocuWare packages that wrap the API in easy-to-use C# code? I have found that for certain operations, using the API with straight POSTs and GETs is problematic (I am doing a lot of that from Visual Foxpro). You can learn more about the .NET packages at:

    https://developer.docuware.com/dotNet/66b2ed1e-2aef-452a-97cd-5014bbf0242b.html

    But if you have to use the more raw GETs and POSTs (as I imagine a college project might require you to do), I am not sure why your code does not work. In reviewing my Foxpro code, your entry point appears to be correct, but I do not try to upload and index the document all at once. I upload it, then index it using a separate POST. On what line are you getting the actual error? Have you tried just uploading the file, and does that succeed? The more you can break the transaction down the better you can debug the problem. The issue might lie with the XML not being in a format DocuWare expects, for example.

    Sorry I cannot be of more help, as on the C# side I use the DocuWare Nuget packages to make life a whole lot easier.

    Good luck!
    Joe Kaufman