RE: Results and questions, Re: Something lighter than a databasefile . . .

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx 
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James H 
> H Lampert
> Sent: Thursday, March 09, 2006 8:37 PM
> To: Midrange Systems Technical Discussion
> Subject: Results and questions, Re: Something lighter than a 
> databasefile . . .
> 
> Well, our experiment with replacing the temporary file 
> with a combination of a *USRIDX and a *DTAQ didn't pan 
> out. In a real-world test, it was either not much better, 
> or even slightly worse.
> 
> One thing, though (and this is starting to look like time 
> to transfer the thread to the RPG list):
> 
> We did determine that writing a duplicate key to a file 
> (and allowing it to fail) was a real killer on speed. Is 
> there a "cheap" way to check for a duplicate key without 
> writing, and that works when you're trying to read the 
> file sequentially even as you're adding to it?

Not sure I'm following you here.  Doesn't seem to make sense to check
for a duplicate key while reading sequentially.

When I check for a duplicate key, I always use random I/O.

The fastest way to do it is with a SETLL or using the SQL IF EXISTS.


> 
> I vaguely remember something about the relative costs of 
> different record-level/native database operations. I don't 
> remember whether it was on this list, or the RPG list, or 
> in a magazine, or a Redbook, or elsewhere, but I do 
> remember something about examples that did exactly the 
> same thing in different ways, and ran at dramatically 
> different speeds.
> 


Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121