Re: PF Compiled Files with Dictionaries vs. SQL-Created Tables

[Jason Abreu <jason.abreu@xxxxxxxxxxxxxxxxxxxx>]

I would tend to agree with you on this point.

Applications should be written to display data in a locale-specific 
format.  The '$' should never be stored, or attached, to a specific 
column because it is meaningless in most locales. The same goes for the 
decimal point and any date-specific formatting.

Jason Abreu
Abreu Innovations, Inc.
jason.abreu@xxxxxxxxxxxxxxxxxxxx
http://www.abreuinnovations.com/

On 2/7/2011 2:15 PM, Bryce Martin wrote:
> I guess I wouldn't be opposed to it being there for those that wanted it.
> It just doesn't feel right to me, that's all.  If you have programmers
> that aren't adhering to the shop standard when outputting to reports and
> screens then they need to be held accountable.  How portable is your data
> if you use these techniques?  I realize that might not be an issue for
> everyone.
>
> I can just imagine someone doing a DSPFMT (its a TAATOOL Command) and
> seeing a list of the field defs.  That would show it as a numeric field.
> Then they query the data and it is all formatted with hiphens, dollar
> signs, commas, periods, or whatever else the person defined.  If I wasn't
> expecting that my first reaction is that there is some crazy data
> corruption.  I just think that data is data, and formatting for reports
> and screens should be done by the respective media.  Just MHO.
>
>
> Thanks
> Bryce Martin
> Programmer/Analyst I
> 570-546-4777
>
>
>
> "caura"<caura@xxxxxxxxxxxxxxxx>
> Sent by: midrange-l-bounces@xxxxxxxxxxxx
> 02/06/2011 02:12 PM
> Please respond to
> Midrange Systems Technical Discussion<midrange-l@xxxxxxxxxxxx>
>
>
> To
> "'Midrange Systems Technical Discussion'"<midrange-l@xxxxxxxxxxxx>
> cc
>
> Subject
> RE: PF Compiled Files with Dictionaries vs. SQL-Created Tables
>
>
>
>
>
>
> Hi,
>
> The dollar-example is indeed a standard example and that's why I didn't
> mention it:
> If you define a fixed pattern for the data
> (ex.: zero suppressed, full edited, minus before, $ after, "CR" , ...),
> All reports etc will contain that format - no effort required.
> And if you need a special report with modified editing,
> Then -and only then- you define it explicitly.
>
> If you don't, and "leave it to the application",
> All applications will create non-corresponding output.
> It will work..., but ... Yuck!
>
> Yes, Luis. There may be environments where "global standardisation" is not
> possible.
> Also, not all businesses that use DB2 are big International companies.
> Editing never has been "an obligation".
> You define it where it can be used and where it can help
> - and you don't define it where it can't be used-.
> Simple pragmatic logic.
>
> If I change old files (with "editing" defined in them) to SQL-tables as
> they
> should be defined,
> Our users - being it standard or power-users - immediately react
> "Hey Guys, you made our data turn out unreadable"
> (not my words, yes IBM, there is a need for this...).
>
>
> Yes, Bryce. You could check and store any editing in the database itself
> and
> we do this for certain limited data.
> This has nothing to do with some extra bytes.
> It's just more work since good "editing-options" make things automatic.
>
> Yes, Rob. You could try to mimic editing with functions etc,
> But then, wouldn't it be much easier, just to implement "editing" in SQL?
>
> And as I stated in my post,
> At the moment one can do editing for numbers, but not for strings,
> Which -for me- is a big lack in DDS also.
> Sorry Eric about mentioning Belgian Bank Accounts, it was just an example.
> (but Belgian Bank Accounts are still used in strictly Belgian Data-stores,
> not ours)
> Editing should be possible on String data with International Bank
> Account-notation.
>
>
> People who don't want to use it. Their choice.
> People who want to use things that always have worked pretty nice, easily
> and straightforward are blocked by this.
> (probably I am the only one).
>
> Luc
>
> PS:
> Why can't there be created "Internal-Pattern" "External Pattern" by ways
> analogue to "regular expressions"?
> In a way it could be used where you want to:
> on Selects (if it's specific), on Data Definition (if it's global), ...
> (sorry, I'm dreaming, please don't react on this).
>
>
> -----Oorspronkelijk bericht-----
> Van: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] Namens Bryce Martin
> Verzonden: vrijdag 4 februari 2011 22:45
> Aan: Midrange Systems Technical Discussion
> Onderwerp: RE: PF Compiled Files with Dictionaries vs. SQL-Created Tables
>
> Rob,
> I understand your explanation.  But here's how I look at data.  If I have
> to do Maths on a piece of data, then its a number.  If I don't, then its
> "probably" best left as a string.  There might be exceptions to the rule,
> but they are definitely few and far between.  I'm not worried about saving
>
> a few bytes because I don't want to store the hyphens.  Pssshhh.  I think
> the cost to store them is cheaper than the cost to reproduce them over and
>
> over again.  I'm in agreement with Eric's post.  Edit code and edit words
> in DDS PF is a no no.
>
>
> Thanks
> Bryce Martin
> Programmer/Analyst I
> 570-546-4777
>
>
>
> rob@xxxxxxxxx
> Sent by: midrange-l-bounces@xxxxxxxxxxxx
> 02/04/2011 04:01 PM
> Please respond to
> Midrange Systems Technical Discussion<midrange-l@xxxxxxxxxxxx>
>
>
> To
> Midrange Systems Technical Discussion<midrange-l@xxxxxxxxxxxx>
> cc
>
> Subject
> RE: PF Compiled Files with Dictionaries vs. SQL-Created Tables
>
>
>
>
>
>
> Bryce,
>
> Storing edited data is one option.  However, do you store all your dollar
> amounts as edited strings?  No.  Yes, granted, that is different because
> you will do math on dollar amounts and you will not on bank account
> numbers (let's leave Mod10 checking out for now).  What Luc is saying is
> that DDS allows you to specify an edit code (or edit word) that "some"
> query tools and that the default for external printer files is to respect.
>
>
>   I am not sure if Crystal reports, Excel or html output will respect edit
> codes or edit words however.
>
> An option to storing the data as an edited string is to read only via
> views.  Views can wrap the number as an edited string.  For example, if
> the table stores bank account as an 11p0 number then your view could use a
>
>
> UDF to easily display that as ####-#####-##.  You save space by packing
> yet get the desired display.  And all tools would respect that, if read
> from the view.
>
> Luc,
> Is this what you are trying to get across?
>
> Rob Berendt