×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
After several tries to respond to this, I can only say that your
approach leaves me feeling ill. My heartfelt belief is that business
data in the database should NOT need to know that "in Belgium, I look
like this, where as in London, I look otherwise. Oops, how should I
look in Spain, or Germany, or Japan?
Is a function called FormatTelephoneNumber( myPhoneNumber : myLocale )
really "Business Logic"? I think not. This would ONLY be useful to the
client application that is exposing this data to the consumer.
Here's the real question... Is DB2 managing screens for your
applications? Is DB2 dumping data directly to your printers? The
answer to both of these is NEVER. The database manages the storage and
retrieval of data. Your applications handle the formatting of that data
into whatever format is appropriate for that application.
BTW, I have NEVER made use of EditCode or EditWord in DDS for PF data.
For screens and print files, sure, but never the database.
JMO,
-Eric DeLong
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of caura
Sent: Friday, February 04, 2011 1:34 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: PF Compiled Files with Dictionaries vs. SQL-Created Tables
Rob e.a,
<quote>
Editing of data is the responsibility of the application
</quote>
???
When I define data, I want the data to be clearly defined:
(for me, since it states "define data",
this indicates it has nothing to do with "business logic",
But everything with data definition.
I surely will be mistaken)
As an example:
If I define a bank account, -for me- It should ACT as a bank account.
(and not -as I read in some posts-
"every application that wants to display or print or ... an account,
should do and redo and overdo the necessary editing".
For me not quiet the way to create applications.
If every application that uses certain data should do editing itself,
This is a splendid example of the opposite of "reuse" and "inheritance"
and
"modularity" and all that modern stuff.
=> if I want an "Employer-reference" of a Belgian Enterprise,
It always has the format "0123.456.789"
So I want it to appear as such and this for every user and every
application.
(without the need for special functions as soon as the data is defined)
=> just a simple 1 time definition in DDS and certainly not
"left to the responsablity of any application that would exploit this
data"
(how many formats that would end up with?) .
=> If I want an Identity-number of one of our Members,
I want it to be shown in every application as a only-positive, zero
filled
number.
= just a simple 1 time definition, and again please not "in every
application???".
=> a Belgian account always has the format "999-9999999-99".
Easy to define 1 time in DDS.
=> if I want to define a European account,
It should be able to edit it as a European account also:
BE12_3456_7890_1234 (with "_" as blanks)
Not possible in SQL but not possible in DDS either (=character-editing)
.
Sorry but for me these examples are just every day data-manipulations
for
over 20 years.
And SQL is unable to deliver these all basic and necessary functions ...
And no, I do not see my colleagues nor me defining and redefining such
trivialities in all our applications.
Luc
-----Oorspronkelijk bericht-----
Van: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Namens rob@xxxxxxxxx
Verzonden: vrijdag 4 februari 2011 15:43
Aan: Midrange Systems Technical Discussion
Onderwerp: Re: PF Compiled Files with Dictionaries vs. SQL-Created
Tables
I am still waiting for the OP to define what editing they meant.
Rob Berendt
As an Amazon Associate we earn from qualifying purchases.
This thread ...
RE: PF Compiled Files with Dictionaries vs. SQL-Created Tables, (continued)
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.