David,

I remembered a discussion awhile back about this, or at least about something similar, so I went and dug up the thread. It may be of interest to you, so check it out: Thread #865460

~~Bonnie


>Kevin,
>
>Thanks for going to the trouble on my account. It was a lot more than I could have asked for. I was hoping that someone could just say off the top of their head. I guess that you haven't completely memorized all the source for C# yet. Don't give up!
>
>My thinking was that setting an index created a hashtable or some other kind of data structure to index by primary key that would entail some kind of overhead in CPU time and RAM, but using Select would result in some equivalent of a table scan, comparing the value in the Select to the column value in every row.
>
>For 1000 consecutive row selections, the slight difference you noted would be more pronounced. For the sake of cleaner code, I think that I will get into the habit of defaulting to the use of Find when tables have single-column primary keys, I just need to think of a way to massage that into my architecture, which, right now, allows you to populate a new or existing DataSet with additional tables by simply specifying a DataSet and the name of the stored procedure.
>
>Thanks for your help and time.
>
>Regards,
>
>David
>
>>Hi, David,
>>
>>I did a test using VS2005, where I pulled down 100,000 rows into a Dataset, and then searched for a single row....using both a FIND and a SELECT.
>>
>>The SELECT performed almost as fast as the FIND. The SELECT ran in just over a second, and the FIND ran in just under a second. I was a bit surprised how close they were. I don't know for a fact what ADO.NET is doing under the hood when you create a primary key. So perhaps a SELECT is fine even for a single primary row.
>>
>>Kevin