Trying to include a $SEQ file in a uar.

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

We use a $SEQ file to store the changes to the structure of the database (it's effectively a table of sql scripts to be run when updating a database). We send patches to the system out as incremental .uar files (So the main release is main_system.uar, then patch1.uar, patch2.uar etc each containing just the changed programs etc). I am trying to get to a state where we can include the 'latest' .seq file (and it's overflow file) in the patch*.uar. It seemed that $res would do this for me, but apparently not. If I include the following bits in the asn file. [FILES] sye_update.seq=$res:sye_update.seq osye_update.seq=$res:osye_update.seq [ENTITIES] ;SYE_UPDATE.SYSTEM $seq:sye_update.seq SYE_UPDATE.SYSTEM $res:sye_update.seq it appears that a $fileproperties can find and use the sye_update.seq to get the file modification date, but a read on SYE_UPDATE.SYSTEM cannot. Does anyone have a technique for releasing 'static data' that is easy to maintain, and applicable to resources settings? Iain

3 Comments

  1. Since the code snippet is just using a filecopy your 'live' and 'training' assignment files could have the sequential file unpacked to different locations based on a file redirect maybe? I haven't checked explicitly but I imagine anything that isn't "4GL aware" will be unable to see inside a UAR file. So database connectors, the xml validator used by xmltostruct etc.


    Author: James Rodger (james.r.rodger@gmail.com)
  2. Hmm, it's something to think about, but it actually brings up another wrinkle,  Our standard config is to have two databases 'live' and 'training' which both run from the same folder system, and thus use the same uar files. However, in the case of patching, we can have the training system use the newer patches before the live system, in order to allow the customers to test the new fixes.  The problem we are encountering, is that if the patch requires a database update, this .seq file lives in one place, and therefore  updates the live database 'too early'.  I was therefore looking for something which could allow us to read data directly from within the .uar files, so the training copy of the .seq (or whatever) file was newer than the live one, and the live one automatically caught up when we altered the asn to point at it.  I was thinking of shifting to using xmlload and storing the data in an xml file, but it's not very performant for the data sizes we are talking about. (the seq files total about 8Mb and the xml output is slightly larger...) I am assuming that other database drives will have the same issue with reading inside the $RES path, however. 


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  3. Hi Iain, I had a similar situation when trying to pack xsd files into a UAR. xmltostruct/schema requires the xsd to be unpacked and can't see it down the $res path. However, the filecopy command will happily read from $res so I use something like this: filecopy "$RES:\xsd\myxsd.xsd", "myxsd.xsd" vFilePath = $item("FULLPATH", $fileproperties("myxsd.xsd", "FULLPATH")) The xsd is now extracted to wherever my assignment file maps it to, and vFilePath holds the fully qualified path, ready to use with xmltostruct. Might something like this work for you? In my situation I can check if myxsd.xsd exists and unpack it only when needed, you'd need some sort of strategy for only unpacking your updates when required I'm not sure how you might go about that just yet. Regards, James


    Author: James Rodger (james.r.rodger@gmail.com)