Recent Posts

Pages: [1] 2 3 ... 10
1
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?
2
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).

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

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.

Thanks.

Chris W.
4
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.
5
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?
6
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.
7
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.
8
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
9
Activant/Prelude Support / Conversion needed
« Last post by DonQuixote on July 31, 2017, 06:38:50 pm »
I need a conversion that will work in the dictionary and in a screen that will zero fill 3 digits but accepts and display a length of 4.
The purpose is that we expanded our territories to four digits but we still have many 3 digit territories.
So if a person enters  "1"  then "001" will be displayed and used to read the TERR file
If you enter "1024" then it will display "1024" and read the TERR file.

The old conversion "MR%3" does not work because it cuts the length to 3 digits; so that 1024 become 024.
Using "MR%4" does not work because "1" becomes "0001" and is invalid because we want "001".



10
Activant/Prelude Support / Re: CUST.LN.NUM in the ORDER.HISTORY file
« Last post by precisonline on July 20, 2017, 03:52:09 pm »
Why not use the line sequence instead; that is, the line number that appears in /SOE?  I would load up the order header, locate the key in <200.M>, and use that position.
Pages: [1] 2 3 ... 10