I have also had odd performance issues in one of my apps. Still can't explain it, one of my queries through the ODBC driver is the user entering an indexed primary key value in the exact data type and format as stored on the AS/400, yet the retrieval time is measured in MINUTES. Sure, this is a million record table, but whoa... Then, using the SAME USER-ENTERED VALUE, I query again only returning all columns instead of just the 2 retreived by the original query and it takes almost no time - seems cached, if you ask me. Another function in my application queries a different table in the same dataset and is quite speedy. It is a much smaller table, about 1500 rows, but even a SELECT * FROM table returned all 1500 or so rows in a fraction of a second. Can't figure it out. I've been over it and over it with the 400 DBAs, and it is also slow when executing similar queries from other sources, such as MS Query in Excel. If you ever find anything out, I would love to know as well. I'm sure my client would love it as well. They accept the 30 seconds to 1.5 minute retrieval times because it saves them a good 20 minutes of double data entry, but it just doesn't sound right to me. Spoiled by .05s query returns from 100k record native Foxpro tables, I guess.

Randy

>Wondering if anybody has any experience using ODBC to go into an AS/400, now known as the iSeries.
>
>We have no problem connecting w/ODBC and getting the job done, but have seen that the performance in a low-load situation is considerably less than SQL Server.
>
>Generally, it is *very* hard to get an apples-to-apples comparison, but we have a dual-processor 500Mhz system w/NT running SQL Server 2000, and one of our baseline simple test queries, SELECT * FROM Mytable, will return about 3600 records/second. Doing the same query from the iSeries gives about 1200 records/second.
>
>We have done a lot of tests, which I would be happy to go into if anyone asks, but at this point are hoping there might be an ODBC guru out there who can help us tweak it.
>
>As always, TIA...
>Ken