|
David,
Well, they were two separate ideas. First I though of a stored procedure
and after that I thought it could be done with a trigger...
I have been swamped with a lot of work this week, so haven't been able to
invest much time on your idea, although it does sound as
an interesting project.
Ok. Let me summarize it in an oversimplified manner:
If you write a stored procedure it would be the equivalent of writing a SQL
program that could be very easily called, as you clearly stated, from non
iSeries apps. I’m not very sure about how you could call a stored proc from
an Excel spreadsheet, though. Maybe with a VB macro?
The main advantage of a trigger is that gets executed by the DB engine when
you do either an Insert, Delete and/or Update to the table, no matter how
that operation is made (DFU, Native RPG, SQL, ODBC, etc). BUT, I had
forgotten that you can’t do an Insert or Update with a BEFORE trigger, so
it’s back to the drawing board with that one.
As I said, it looks like a nice project, and a good way to keep a record of
changes. I’ll try to give it a little time and if I get any other ideas I’ll
post them back.
BTW, the main reason I’m being swamped with work is that I have just
returned from a long family vacation, including two weeks in Europe, with a
short (but very nice) stop in Paris (your “work-town”, I believe…)
*****
Just thinking about it... If your main input method is an Excel table that
gets inserted into, say, TEMPFILE, maybe you could write an AFTER INSERT
trigger to TEMPFILE that writes all the Updates and Inserts needed to you
main client file. Just a quick idea that needs a little more research.
*****
Regards,
Luis Rodriguez
IBM Certified Systems Expert — eServer i5 iSeries
--
On Fri, Sep 17, 2010 at 3:52 AM, David FOXWELL <David.FOXWELL@xxxxxxxxx>wrote:
Thanks Luis, when I posted, I had vague ideas of triggers and stored
procedures.
I've never written one nor the other, although I vaguely know what they
are.
I think what you're saying is add a trigger to my client file which would
have to become a DDL table in that case?
In the trigger, I'd write the update part.
Then I'd put my insert in a stored procedure that would be called for each
client?
Doesn't having the trigger hide what's going on from other developers?
I was thinking, well, there's no real advantage over the original RPG
program. But then I thought of what I might gain personally. If I understand
correctly, the stored procedure could be used easily from non iseries
application. The user is currently sending the information via Excel that I
transfer to the i, run some interactive SQL then the RPG on. Couldn't he
access the stored procedure directly from the Excel sheet?
-----Message d'origine-------
De : midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de Luis Rodriguez
Envoyé : jeudi 16 septembre 2010 20:32
À : Midrange Systems Technical Discussion
Objet : Re: Can I replace RPG with SQL?
David,
Maybe you could insert the UPDATE part of Charles's code in a
"BEFORE INSET"
trigger...
Regards,
Luis Rodriguez
IBM Certified Systems Expert - eServer i5 iSeries
--
On Thu, Sep 16, 2010 at 12:22 PM, Charles Wilt
<charles.wilt@xxxxxxxxx>wrote:
Good catch...guess I shouldn't answre posts quickly beforeleaving for
lunch! :)ClientVersion) (select
how about:
update ClientTable A
set ClientVersion = (select max(CilentVersion) + 1
from ClientTable B
where a.clientID = b.clientID) where
clientID in (select clientID from NewClientTable);
insert into ClientTable (ClientID, ClientName,
ClientID, ClientName, 0 from NewClientTable);table. Odd
Charles
On Thu, Sep 16, 2010 at 11:39 AM, Morgan, Paul
<Paul.Morgan@xxxxxxxxxxx>
wrote:
Charles,ClientVersion = 0 and the ClientID is in the transaction
He wants to set ClientVersion to 1 + Max(Clientversion) when
but that's what he wants. Your Update bumps up the clientversion in
all the records.client file
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Paul
Principal Programmer Analyst
IS Supply Chain/Replenishment
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
Sent: Thursday, September 16, 2010 11:28 AMwrote:
To: Midrange Systems Technical Discussion
Subject: Re: Can I replace RPG with SQL?
Assuming ClientID is unique in both tables....
update ClientTable
set ClientVersion = ClientVersion + 1 where clientID in (select
clientID from NewClientTable);
insert into ClientTable (ClientID, ClientName, ClientVersion)
(select ClientID, ClientName, 0 from NewClientTable);
HTH,
Charles
On Thu, Sep 16, 2010 at 9:44 AM, David FOXWELL
<David.FOXWELL@xxxxxxxxx>
maybe.....I don't think this is easy enough to make it worthwile with sql,
but,
clientId 15 becomes 'Smith'. But I can't just update the
Here's my client file that I want to update :
ClientId ClientName ClientVersion
15 Bigs 0
I receive a file containing clientId and the new name of the
client, eg,
from this work file. I need to archive the original name, so I havefew thousand
this kind of representation after the update :
updated to n+1 and a new line is written to the file. So, in the
ClientId ClientName ClientVersion
15 Smith 0
15 Bigs 1
There's a timestamp field among the other fields. Version 0 is
always
example, I've updated the line Bigs and I've written the line Smith.
now to 'Eggs', I want to see :
So, version 0 is the current version and 1 is the old one. If I
change
ClientId ClientName ClientVersion
15 Eggs 0
15 Bigs 1
15 Smith 2
I ask because I get this request now and again, for a
clients at a time. I'm having to use an RPG to write to the clientfor that RPG.
file, but I always end up using SQL to prepare a work file
(MIDRANGE-L) mailinglist
Thanks.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
listTo post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,--
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please
take a moment to review the archives at
http://archive.midrange.com/midrange-l.
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,list
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please
take a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,--
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please
take a moment to review the archives at
http://archive.midrange.com/midrange-l.
This is the Midrange Systems Technical Discussion
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,please take
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting,
a moment to review the archives at--
http://archive.midrange.com/midrange-l.
This is the Midrange Systems Technical Discussion
(MIDRANGE-L) mailing list To post a message email:
MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting,
please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.