RE: SQL - File staying locked.

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.