convert c-star fields into SC-star fields

Author: i2stiller@gmx.de (istiller)

Hi freaks

 

One simple question :-)

How to convert data from C-star fields into SC-star fields?

My task is to change the defintion of some field from C* into SC* resp. U* into SU*.

First I did export the data into TRX files (old defintion), then I did change the definition, rebuild ULANA, create new SQl_Script, create new tables and did reload the data from TRX

Looks good on first sight but the then I saw the mess:

The first SU* field will contain all data in the internal TRX-format, like the old definition for the table (only first field on database)

So how to persuade UnifAce to load the date into each  new fields?

BTW:

I have to use UF8 due some circumstances.

And ICOMP only support TRX  (or?)

 

Any idea  ...

 

Regards Ingo

 

 

 

 

 

 

11 Comments

  1. Hi "freak" ;-)

    Did you import the data (old definitions) using a map file? In case you do not specify one then Uniface will import the data according to the table definitions it finds in the TRX export file. And in case you're using Uniface 8.4 then it's sufficent enough to add a hash sign (#) to the end of the copy (/cpy) instruction and then Uniface should write the data according to the compiled entity descriptors in ULANA.

    /cpy trx:mytable.trx def: #

    Hope this helps.

    Best regards,
    Daniel

    *** Usual disclaimer ***


    Author: diseli (daniel.iseli@uniface.com)
  2. Hi Daniel

    Yes, I did try a MAP file -> doesn't work

    But I will try the a hash only :-)

    Regrads

    Ingo

     

     

     

     

     


    Author: istiller (i2stiller@gmx.de)
  3. Hi Ingo,

    think uniface still puts all data of the variable length fields in one database field,
    no matter what interface you give the different fields.

    Think it's implemented deep down in the kernel/driver.

    This "overrules" all others.

    Success, Uli


    Author: ulrich-merkel (ulrichmerkel@web.de)
  4. No Uli,

    the SC* format causes uniface to split the variable length fields into separate fields in SQL server, (although with one odd named field containing some kind of breakdown as well I think).

    We use this a lot. Otherwise we wouldn't be able to get at the data from Crystal reports and such.

    regards,

    Iain


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

    thanks for this (new) experience.
    Looks like I made a mistake similar to Ingos when I tested it.

    Success, Uli


    Author: ulrich-merkel (ulrichmerkel@web.de)
  6. Hi Uli

    I know about the difference about C* and SC*.

    That's wyh I (and Iain) convert fields to SC*

    Ingo


    Author: istiller (i2stiller@gmx.de)
  7. ThanX Daniel

    '#' will work, but not with ULANA but with a new URR file :-)

    I will check, if there are further problems, but for the moment it looks like the field a correct filled with data.

    Regards Ingo

     

     

     

     

     


    Author: istiller (i2stiller@gmx.de)
  8. Hi Ingo,

    Yes, I forgot about that - sorry.

    I'm always using $SEARCH_DESCRIPTOR=DBMS_FIRST and then the entity descriptors are read from ULANA - these are usually the most up-to-date ones. When $SEARCH_DESCRIPTOR is not specified then the descriptors are searched for in the URR file (FILE_FIRST) and in case it still contains "outdated" information then the mapping will of course go "wrong" - so to speak. ;-)

    Regards,
    Daniel


    Author: diseli (daniel.iseli@uniface.com)
  9. Hi,

    As Ingo seem to have got his answers, here some analogous questions:

    I suppose that SC* fields do need more space than C* as SC* is mapped as TEXT and that seems to always allocate at least 1 page of the database (MSS) ?

    If you go from "MSS mapping1 C*-field" to "MSS mapping2 C*-field", there seem to be quite a different qry-script created (longer varbinary in the main-table for mapping2), so I suppose that it's not possible to use the same table and neither to move the data by some general Sql export-import ?

    If you would like to convert data at the customers (VAR) environment with "idf /cpy",  you will probably need a development license that works for all your XXX number of customers (runtime-license not enough) ?

     

    Regards RogerW.

     


    Author: rogerw (roger.wallin@abilita.fi)
  10. Hi Roger

    A runtime-licence should be enough.

    To start IDF for converting data us the switch  /rma  (UF9 )

       /rma /cpy def:table.* xml:

     

    Try also only  /rma  with a runtime licence :-)

     

    Regards Ingo

     

     



    Author: istiller (i2stiller@gmx.de)
  11. "/rma" Nice feature....


    Author: rogerw (roger.wallin@abilita.fi)