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