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



Rob:

Sorry, I was out-of-office for a couple days enjoying my time. You wrote a fine 
followup, but what the heck... maybe you're right. Do you think my revised 
subject line could raise some interest?  :-)

Tom Liotta

midrange-l-request@xxxxxxxxxxxx wrote:

>   7. RE: Single record access really required (was RE: Views and
>      (rob@xxxxxxxxx)
>
>Tom,
>
>I suggest you repost this with a new heading, and as a totally new subject,
>(not as a reply).  Many have tuned out of this thread and this is too cool
>to just bypass.  I already have a reply in mind.
>
>Rob Berendt
>
>midrange-l-request@xxxxxxxxxxxx wrote:
>
>>   4. Re: Single record access really required (was RE: Views and
>>      (Simon Coulter)
>>
>>It depends. In many cases SQL will be faster but there are other cases
>>where native I/O will be faster. Which is faster is usually a case of:
>>    o processing sets then use SQL
>>    o processing single records then use native I/O
>>however both methods can be used interchangeably, in the same program,
>>on the same files and for the same purposes.
>
>It's a bit more complicated than that and will only get more so. Consider
>in particular V5R3 SQL's encrypt/decrypt feature. With external
>requirements such as HIPAA, this will be critical for many databases; but I
>have no picture at all how native I/O will play with it. There are a lot of
>other SQL features that also cause native I/O fits. Need to verify a
>CustNo? Well, if CustMast has an encypted field, maybe you better look at
>SQL.
>
>I'm starting to suspect that speed comparisons aren't nearly as important
>as determining fast access techniques for SQL. Period.
>
>Off on a tangent, I swear another post referred to the inability of DB2/400
>(yeah, I know... the name... but I don't care) to update JOIN views. Maybe
>ten years ago, I think at COMMON, I saw a presentation that described the
>technical obstacles that had to be overcome in order to make it possible. I
>never questioned the problem again.
>
>However, things are slowly beginning to change. Two articles related to the
>idea:
>
>http://www-106.ibm.com/developerworks/db2/library/techarticle/0209rielau/0209rielau.html
>http://makeashorterlink.com/?I27224E57
>and
>http://www-106.ibm.com/developerworks/db2/library/techarticle/0210rielau/0210rielau.html
>http://makeashorterlink.com/?W26212E57
>
>For everyone, if you don't nose around out in places like developerWorks
>every once in a while, search on topics, etc., you can't know what you're
>missing.

-- 
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertech.com


__________________________________________________________________
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.