New POS Software Feature for Amicus - Image Manager

A feature that will appear in the next version of Amicus is the long-awaited Image Manager. This allows the user to have a central place in the database to put images needed by the business so that each till can access them easily. Prior to this, all customisableimages had to be placed in a shared directory on a server somewhere.

There were several uses for the image manager straight away:

• The company logo on reports
• The logo on strip printer receipts
• The images used for the secondary display
• Assigning images to product pad buttons

Once the image manager was created, we then decided that we needed our data synchronising service to be able to cope with images. This would be powerful, as an owner of a retail chain could synchronise out branding changes, secondary display images etc.

There was a technical problem though. Currently, sync gets data from the database in XML format. It then compresses it, moves the file to the remote location, and then imports the XML. But how do you place binary data into an XML file? It didn’t take long to find that you simply add the BINARY BASE64 keywords to the end of the SQL statement. For example: select * from sale for xml auto, binary base64.

The problem after that was to figure out how we were going to import the binary data at the other end. At the time, we were using the OPENXML method for retrieving the data from the XML file. This method did not support reading in the base64 binary data. If we attempted to import the data, it would import it in its base64 format (i.e. the values would not be the same). The first set of suggestions on the Internet suggested that we needed to create a .NET DLL that had an exposed function to do the change, and then register the DLL with the SQL server, allowing us to call it. This seemed like a lot of work for something that should be easy. Also, some of our clients use SQL Server 2005, which does not support registering .NET DLLs.

A bit more searching found another suggestion. Rather than use the OPENXML method, we used the following approach instead:

DECLARE @idoc xml

SELECT @idoc=”...XML...”

This way was much more useful, as it coped with base64 binary data naturally.