RE: Can I replace RPG with SQL?

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 before

leaving for

lunch! :)

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,

ClientVersion) (select

ClientID, ClientName, 0 from NewClientTable);

Charles

On Thu, Sep 16, 2010 at 11:39 AM, Morgan, Paul
<Paul.Morgan@xxxxxxxxxxx>
wrote:

Charles,

He wants to set ClientVersion to 1 + Max(Clientversion) when

ClientVersion = 0 and the ClientID is in the transaction

table. Odd

but that's what he wants. Your Update bumps up the client

version in

all the records.

Paul

Principal Programmer Analyst
IS Supply Chain/Replenishment


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:

midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt

Sent: Thursday, September 16, 2010 11:28 AM
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>

wrote:

I don't think this is easy enough to make it worthwile with sql,
but,

maybe.....

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,

clientId 15 becomes 'Smith'. But I can't just update the

client file

from this work file. I need to archive the original name, so I have
this kind of representation after the update :

ClientId ClientName ClientVersion
15 Smith 0
15 Bigs 1

There's a timestamp field among the other fields. Version 0 is
always

updated to n+1 and a new line is written to the file. So, in the
example, I've updated the line Bigs and I've written the line Smith.

So, version 0 is the current version and 1 is the old one. If I
change

now to 'Eggs', I want to see :

ClientId ClientName ClientVersion
15 Eggs 0
15 Bigs 1
15 Smith 2



I ask because I get this request now and again, for a

few thousand

clients at a time. I'm having to use an RPG to write to the client
file, but I always end up using SQL to prepare a work file

for that RPG.

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


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

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