Recent Posts

Pages: [1] 2 3 ... 10
Activant/Prelude Support / Re: Process Definition Sort mv
« Last post by precisonline on March 28, 2018, 01:42:24 pm »
Any single BY.EXP is going to make the whole deal BY.EXP.  The selection criteria on a /PD.S translates eventually to a TCL SELECT statement, and that is true for a TCL statement.
Activant/Prelude Support / Process Definition Sort mv
« Last post by DonQuixote on February 01, 2018, 10:53:11 am »
/PD.S     Process Definition Sort
is there a way to get a mix of  BY and BY-EXP in the process?
Announcements / EUG 2017
« Last post by precisonline on September 06, 2017, 07:49:13 pm »
Who will be at the Epicor User Group meeting in Minneapolis in October?
Your problem shows one of the philosophical differences between an SQL TABLE and a UniData/MultiValue Dictionary.  The TABLE forces the data into a particular structure, while the Dictionary allows you to access the data by multiple methods.

For example, our CUSTOMER file has TAX.JUR.NUM as a Multi-Valued field (Attribute 16).  It also has TAX.JUR.NUM1, TAX.JUR.NUM2 and TAX.JUR.NUM3 defined for the first three values (Attributes 16.1, 16.2, and 16.3).  Which field(s) would you want the SQL SELECT to return?  That's why LIST ALL provides the data by Attribute, with little regard to the Dictionary (it converts Dates, apparently).

Even if you applied CONVERT.SQL to a file, you may still have issues with the Multi-Valued fields.

*** Warning ***  Gory "Under-the-Hood" details follow

A "roll your own" solution would be to write a program to build the field names for the LIST/SORT command from the SB+ Dictionary Items.  In the file's DICT, these items have "Z" in Attribute 1.  Attribute 2.1 is the corresponding Attribute number (zero for Derived fields), and Attribute 2.2 has the Value number (zero for the entire attribute, -1 for MV fields). 

The SB+ field names are the same as the UniData field names, with a prepended dot.  E.g., SB+ stores its information in .PROD.NUM for the UniData field PROD.NUM (/FD maintains both).

U2 Programming Questions / Unidata Equivalent of SQL > SELECT * FROM FILENAME
« Last post by Chris Weitzel on August 23, 2017, 02:55:56 pm »

What options do I have for (easily) doing a complete data dump of a Unidata file, including field names, without having to name each field?  I'm wanting something like SQL SELECT * FROM FILENAME.  I need the data displayed horizontally, (ideally) delimited, with output to a file.  Not too much to ask, is it?

I have experimented with LIST.ITEM and LIST ALL...  They both have their weaknesses.  For example, LIST.ITEM output is vertical and does not contain field names.  LIST ALL doesn't really list every attribute - I.e., multi-value fields are excluded.


Chris W.
Activant/Prelude Support / Re: Conversion needed
« Last post by DonQuixote on August 23, 2017, 01:08:59 pm »
Yes, input conversion.  Yes, stored with leading zeros.
Activant/Prelude Support / Re: Conversion needed
« Last post by precisonline on August 07, 2017, 11:26:44 am »
Tom that's awfully clever.  I don't know that I can improve upon it without writing some code.  We're really talking about an input conversion, right?  You want the value stored with the extra zeroes right?
Activant/Prelude Support / Re: Conversion needed
« Last post by Tom Pellitieri on August 01, 2017, 02:06:50 pm »
I tried "MR#%3" which gave me these results:

1 -> " 001"
12 -> " 012"
123 -> " 123"
1234 -> "1234"
12345 -> "2345"

Note that there is a leading space, but you should be able to trim that out.
Activant/Prelude Support / Re: CUST.LN.NUM in the ORDER.HISTORY file
« Last post by precisonline on July 31, 2017, 06:57:00 pm »
Sounds like a fantastic solution.
Activant/Prelude Support / Re: CUST.LN.NUM in the ORDER.HISTORY file
« Last post by DonQuixote on July 31, 2017, 06:42:26 pm »
They finally accepted the fact that lines number were unique but complicated the situation by making me replace kits with the kit parts.  My solution was to use the line number and .1, .2, .3... for the kit part positions.   :o
Pages: [1] 2 3 ... 10