× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.