There’s nothing quite like logging in to a customer’s system first thing Monday morning only to be greeted with this:
I discovered this when I wasn’t able to log into the customer’s ILINX Capture implementation. The logged error (failure to locate the SQL Server) led me to take a look at the SQL Server’s configuration to confirm that its service was not running on either node of the cluster, and the error I got when trying to start that (a clustered resource could not be activated) led me to check on the clustered resources themselves. Continue reading →
For Existing Applications: As I mentioned before, the decision to enable FILESTREAM should be done during the planning phase. If you perform this process on an application with a lot of content, it can be a very time costly endeavor with a big performance impact to the server. Also, after the move from BLOB to FILESTREAM, you could have a fragmented database. The BLOB to FILESTREAM process can definitely be done on an existing system, just be sure to plan accordingly and allow for sufficient time.
After step #10 of my previous blog post (all the data is copied and you have deleted the BLOB column), you will notice that the database file size hasn’t decreased. This is remedied easily enough be executing a DBCC CLEANTABLE command. The DBCC CLEANTABLE command will reclaim the space from the dropped variable length column. For example, if your database is named ILINX_CS and your application is named Sample Application, the query to do this is:
By design, ILINX Content Store stores documents within the SQL database as BLOBs. There are many advantages to this design (security, performance, etc.) but sometimes there is a reason to store the documents outside of the SQL database. SQL Server has a method to do this called FILESTREAM. FILESTREAM integrates SQL Server with the NTFS file system by storing varbinary(max) data outside of the SQL database. FILESTREAM uses the NT system cache for caching file data: this helps reduce any effect that FILESTREAM data might have on Database Engine performance. The SQL Server buffer pool is not used; therefore, this memory is available for query processing.
One of the main reasons to implement FILESTREAM would be because your documents are generally larger than 1MB in size, storing them outside the database can have a performance advantage. If these are TIFF documents, then this 1MB threshold would be on a per-page basis. This is due to how ILINX Content Store stores TIFF documents. By design, ILINX Content Store splits multipage TIFFs into single pages to allow for users to perform actions on single pages of a document: things like a reorder of pages, single page delete, or rotation. Continue reading →
We recently had a customer who needed to migrate off of an aging and highly customized Capture/indexing/workflow one-off solution. At the center of many of their form types in this system was a repeatable field collection object that functioned much like how you would expect a .NET DataTable control to function – values could be added horizontally to the current “row”, and at the end of it you could hit enter and a new “row” would be added. As you moved through, you also had the ability to validate the line item as a whole. In other words, nothing too out-of-the-ordinary.
Unfortunately, this stood out as a red flag for both myself and my coworker when we first saw it, since we were migrating the client to Kofax Capture. There’s nothing inherently wrong with Kofax’s flagship product, in fact it is an excellent tool for getting content where it needs to be, often in record time. One thing it doesn’t do well out-of-the-box, however, is table fields. Defining one looks normal enough, but when you actually get the chance to index them, each column ends up being a standard index field. Needless to say, turning the table 90 degrees counter-clockwise and forcing keyers to manually delimit values is not an ideal experience, especially when 99% of your form is tables that need to be indexed. Continue reading →
I was working on a project recently for a customer that was upgrading their Kofax versions and making some enhancements to a custom Kofax panel that we had written for them some time ago. Like any good developer, I migrated the code for the custom panel to the latest version of Visual Studio I had, (in this case, Visual Studio 2012). I had finished development and was discussing installation when the customer requested an MSI package to install the custom panel. Unbeknownst to me, Visual Studio 2012 had dropped their support for the easy, drag and drop, built in set up and deployment project to create MSI’s.
In doing some research, I found many developers had migrated to using the open source WiX product to create MSI packages, (http://wix.codeplex.com/). One can download WiX and integrate it directly into Visual Studio. Everything was fairly straight forward on following their tutorials except for one snag: in order to get the custom Kofax panel to install correctly, I had to register the custom DLLs as COM Components, not in the GAC. After a lot of head scratching, I finally figured out that I could use Heat (one of the WiX tools) to create a registry file of the DLLs to include in my WiX set up project. You can find out more about Heat here: http://wixtoolset.org/documentation/manual/v3/overview/heat.html. After the file was generated I was able to take the output of the Heat generated file and include it in my WiX install project to register the necessary DLLs. To do this, I followed these steps: Continue reading →
ILINX 6.X is an easy to configure and easy to use software package to scan, index, and provide workflow. The workflow steps are based on IXM (ILINX eXtension Modules) that are very similar to a programming language. There are several different types of IXM’s available out of the box. The following is a quick listing by name of the out of the box IXM’s:
By using the IXM’s, the designer of a workflow can have a batch move through single or multiple steps to perform any required task.
In addition to the IXM’s there can be actual code executed through a Client Side Extension or through a Server Side Extension. So there is little that cannot be accomplished using the ILINX Capture workflow IXM’s.
This week I would like to concentrate the discussion on a single IXM Database Lookup. The Database Lookup IXM is one of the most powerful when it comes to interacting with entities outside of ILINX. It not only allows ILINX to perform a database lookup and return column values to the Batch Profile or Document fields, but it also allows for the update of a database table’s columns. Continue reading →
I have been doing document conversion for roughly 15 years and there are numerous applications you can choose from that are a complete waste of time. I have unfortunately had the opportunity to work with some very cumbersome and complicated applications over the years. One of the applications we were using had modules you would have to open separately for every step in the conversion process. After scanning you would have to open the import module then you would have to open another module for document classification then another module for indexing then another module for Quality Control and another module for releasing the final product. I was introduced to a new application called ILINX Capture that changed my entire workflow. I fell in love with it. Now, I no longer have to open a bunch of separate modules to complete the conversion process. The conversion process takes place all in the same window document classification, QC, indexing, etc. ILINX Capture is so easy to use and a complete time saver. I recommend checking it out if you find yourself wasting time going through unnecessary steps when capturing and indexing your content.