|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
