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