It is no secret that read performance can generally be improved by the age-old “blocking” mechanism whereby many rows are fetched at once in preparation for a program to process them. So how is blocking done in the client/server world? Assuming that the good old IBM i will be the server, the following code samples (C#, Java, VBA, and DRDA) show an example of how to increase the amount of data that can be transferred from the server to the client.

C# Using ADO.NET and the IBM DB2 UDB for iSeries .NET Provider

For applications that need to buffer large

Concerning your article Update One File Based on Another File, I would agree that the IN is more intuitive than the EXISTS. When looking at the volume of data, possible number of rows to update, and the rows returned for the IN, is there a preferred method if considering performance? Does the IN or EXISTS result in better performance under certain conditions?

–Sarah

The prevailing wisdom is that EXISTS currently tends to outperform IN. Here are comments from two readers that support that position.

A nice consequence of going the IN route (as opposed to using EXISTS) is that,

My organization has five different i/OS partitions. Yesterday, I thought I was working on a test partition green screen and it turned out that I was signed on to a production system. Worse, I deleted a production file and it caused a lot of problems. Can you think of any good way I can stop that from happening in the future?

–Jim

One of the few problems with i/OS is that there isn’t any “are you sure?” button that pops up when you’re going to delete a file. And in one of the few areas that I think Windows has