Re: Can I replace RPG with SQL? -- MIDRANGE-L

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

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