No announcement yet.

I figured out why it's a bad idea to port SoapWare to MySQL

  • Filter
  • Time
  • Show
Clear All
new posts

  • I figured out why it's a bad idea to port SoapWare to MySQL

    Short answer: 'cause then you can't use SW to store scanned docs. But that was the whole reason for using MySQL in the first place!

    Long answer: Ok, it's taken me a few hours, but now I understand more about BLOBs and databases than I ever wanted to.

    SOAPWare likes to store scanned images directly in its database as binary objects. From what I read, this is something of a no-no, for many performance-related reasons. It was a design decision that DOCS made, and not a very good decision, IMHO.

    As long as you're storing ASCII text in a database field, it doesn't matter which DB application you are using on the back end. Where they differ is how they directly store binary data.

    The issue is that you need a way to escape out the quotes and double quotes. Microsoft gives you the command WRITETEXT in Transact-SQL, which has no equivalent in MySQL.

    To put a TIFF file into MySQL, you have to put a slash before each quote or double quote. I tried doing this on a sample TIFF and got it into the sw_image database, but I could not convince the SW client app to open this item. It choked on the slashes.

    So accessing images is inherently incompatible with MySQL in SW 4.8, because even if you could work around ImageImporter's inability to load a TIF into the database with a PHP HTML application (for example), you can't get the data out with the SW client application. Yucky.

    One hopes that DOCS are using a document directory to store scans, and merely putting the filenames in the database in the next version of SW.

    So much for end-user improvements...the year-long MySQL experiment is a failure. Now, are we gonna spring for the $1800 SQL Server license? Or hope we don't scan more than 2Gb of documents?!