convert c-star fields into SC-star fields

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 ***

Hi Daniel

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

But I will try the a hash only :-)

Regrads

Ingo

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

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

Hi Iain,

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

Success, Uli

Hi Uli

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

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

Ingo

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

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

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.

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

"/rma" Nice feature....