I have had to do that in my Imaging Apps for Passport Canada. What I did was create a temporary DB table with a blob column but use a auto-incremented sequence number as part of the image's primary key on the TEMP table. Then, using the basic FileRead() method syntax read 32K "chunks" of the blob data at a time & store that into the TEMP table's blob column with an UpdateBlob command on each FileRead loop cycle. At the end of the TEMP Blob table load (aka the end of the FileRead loop), I called a DBMS Stored Procedure passing the image's primary key of the TEMP table to the SP. In the SP, I would loop through the TEMP table blob data & reconstruct the entire Blob data in the SP's work area. From there, the SP would load the fully reconstructed image into the proper Blob table & delete the TEMP table blob rows. That gets around using all that client machine local storage that can affect the App user.
You could also keep the image "chunked" in the DBMS & read the image back to the client using a SelectBlob command loop using the Blob Table's image sequence number to keep the binary chunks arranged properly. Then use the basic file FileWrite command syntax to write it to the client's PC's temp browser / mobile work area. Once the entire image has been recreated on the client side - then assign the image file to the Appeon Web/Mobile Apps appropriate image control.
Note: You could also optimize the Blob interactions by controlling the FileRead command loop as to when the UpdateBlob command is fired. That is for example, have an App INI file setting that set's the "trigger" point when the UpdateBlob command is to used. Thus, you could have the loop write 64K, 128K, 256K, etc blob chunks to the TEMP table instead of just the 32K default. Thus, allowing you to optimize the network traffic and Blob processing overhead of your DBMS via an INI setting.
Food for thought. HTH
Regards ... Chris
Appeon: Director, Developer Relations.
Thank you very much for the workaround. It is a great way around the issue.
This is another great idea for managing the Appeon Web image transfrence from the Web Server to your Web Browser based PB Apps. However, keeping duplicate images on the Web Server when you have a plethora of Blob equivalents - especially when you have millions of blob rows - may not make sense.
My suggestion - and what I have done in the past - is to use a PB based Web Service that extracts the Blob image into a Web Server temporary work folder. It then returns the fully qualified URL path to the image to the Appeon Web based App. Which then assigns the URL to the appropriate picture control as outlined by the previous response. This should now render the image within the Web App without the heavy blob tranfer.
Note: I would also recommend creating a PB batch App that runs on a MS-Windows timer service that fires once an hour (or whatever you decide is appropriate) to cleanup the Web Server temporary work folder of image files - for example, image files older than todays date. That way, the image work folder is always "self cleaning".