|
Hope I didn't offend. Could see I was right on the mark though.
Anyway, if I did use the server approach, what's to stop the server from
leaving the locks open? Granted, in theory, that would be one tight
module to test the snot out of and get right.
I can see some people adapting to the externalized I/O model, but only a
small percentage. "What? I can do a chain in my rpg, or I can: write a
totally separate program, call it with a bunch of parameters, etc?"
Granted, you can externalize the security, etc, but unless you get 100%
adoption within an organization, all it takes is one person to trash it
all. I just don't feel strong enough about externalizing I/O to fight
that battle.
Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin
"Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
04/25/2003 09:40 AM
Please respond to Midrange Systems Technical Discussion
To: "Midrange Systems Technical Discussion"
<midrange-l@xxxxxxxxxxxx>
cc:
Fax to:
Subject: RE: SQL - File staying locked.
> From: rob@xxxxxxxxx
>
> select price into :listprice from itemmaster
> where itemnumber=:itemnum
>
> I can just see Pluta, "I wouldn't use a cursor either, I'd use a
> traditional rpg chain." :-)
Doesn't it strike you as odd that you are even pre-quoting my arguments?
Like, maybe you should consider using native I/O where it makes sense
rather
than unwavering adherence to SQL? Just a thought.
As to the locking issue, there might be one other radical solution - use a
client/server approach. Send requests to a data queue, let a server read
it
and send the result back. Sure, there's overhead, but it might be less
than
the overhead of opening and closing a cursor, and it would certainly keep
the number of locks down. And if the logic were embedded in a server, I'd
be less worried about what you actually used - native I/O, SQL, or MI, for
all I care - since the code is encapsulated.
Joe
_______________________________________________
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.cgi/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.