× 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.



Sorry guys, not following this, since there is a production issue.
Agree that the app need to change but the things behind this is more
political than technical.

Thank you so much all
On Jan 6, 2014 9:59 AM, "Henrik Rützou" <hr@xxxxxxxxxxxx> wrote:

William that should be


On Mon, Jan 6, 2014 at 3:58 AM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Silliam

you are out in discussion with people that suggest you replace
the house if you down like the handle on the maindoor!


On Mon, Jan 6, 2014 at 3:46 AM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 05-Jan-2014 13:58 -0800, D*B wrote:
On 05-Jan-2014 12:47 -0800, CRPence wrote:
<<SNIP>> If the RRN is acceptable [I agree with both Birgitta and
Dieter that using RRN should be avoided], then a simple means to
circumvent the lack of the year data <<SNIP>>

using RRN is bad design and bad design will be punished, if not
today, so in the future, when you aren't expecting it. The original
application could not be stabilized without changes to this
application - thinking about this and that we would know the time,
when it fails, I would simply recommend to STRJRNPF to all files!!!,
so that you could see, what had happened and the effort would be
minimized to repair. Regardless what some people might tell: this
would have no impact to your running programs!!!

Seems you may have missed my comments... so I included the pertinent
portion of my quoted text in my prior reply [using conventional USENET
formatting, and\thus giving very clear contextual reference]. I in no
way contradicted any prior implications that use of the RRN was a poor
choice\design. I totally agree that using RRN is a poor means as a
/solution/. I merely offered that, if they were going to use RRN [e.g.
for their trigger] anyhow, as they had alluded they might, then there
was something else that might be helpful without any need for any of an
INSERT TRIGGER, journaling, or altering their table, and accomplished
possibly even without another table by coding that _circumvention_ in
their query.

In my reply prior to that, I had clearly shown a means to implement a
resolution by using the keys [i.e. keyFld1...keyFldn] in the original
file; specifically to avoid using the RRN.
http://archive.midrange.com/rpg400-l/201401/msg00037.html

However I also accept that some people will do what they will do, and
that they may have their reasons to do so [no matter how irrational or
difficult to convey their implied /requirements/]. And I accept that
they either may be able properly to ensure or unfortunately may be
unable to ensure, that their assumptions will hold; if the latter, then
suffer the consequences.

Of course while they could fail at using RRN, they could just as well
fail at using triggers, fail at using journaling, or fail at using the
more ideal implementation of correcting the database and application(s)
to store an appropriate tuple that includes the required date\timestamp
data irrespective of normalization. I would consider both the use of
journaling and the use of a trigger for the purpose of pushing and
therefore obtaining that required information externally, also to be
effective circumventions vs final solutions.

Maybe the better idea would be to replace this application, before it
is replaced by some MS toys - then journaling and commit would no
longer be an issue...

I see no reason avoid correcting the application, irrespective the
claim of a requirement that the files can not be changed. So again, I
agree that a "better idea would be to replace this application"; in
effect, they could replace the application with a corrected version of
the application that properly stores the necessary information with each
database row. Doing that, I would consider a solution, not merely a
circumvention.

--
Regards, Chuck
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.




--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>





--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.