Hi Ron;

   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.