Hmmm, well I get ToolTips ... dunno why you didn't.

LOL! No, I do not live in Leavenworth!! A little too kitschy and touristy ... all those Bavarian chalets all over town!!! But my main problem with it is that it's out in the middle of nowhere! At least Ellensburg is a major truck stop along I-90! Truckstop USA, as we like to call it ... our only claim to fame (although we are a college town as well ... Central Washington University). We had an employee a few years back that lived in Leavenworth and she called it "Heavenworth" ... the mountains in the area *are* pretty ... we frequently go hiking up there in the Icicle Creek area.

I'm not a Washington native (which you may know if you've read some of my other posts). I moved up here from Napa 5+ years ago and I frequently miss California (although I only lived *there* for 6 years). Eburg's not that bad a place to live for a few years ... we're very close to the mountains for hiking and only 100 miles from Seattle. But I certainly don't intend to spend the rest of my life living here.

~~Bonnie


>Thanks, that worked. I wish that the interface made use of alt tags to simulate tooltips, but I haven't explored it much and the purpose of the button is explained by the status bar message.
>
>I looked up Ellensburg online and now realize that you do not live in Leavenworth and walk to work in wooden shoes. Pretty ignorant for a Washington native and Husky, but I spent all my time doodling class diagrams during geography class.
>
>>David,
>>
>>I'm pretty sure you can still view the whole thread. Once you click on the Thread #865460, go to the bottom of the page. Hover your mouse over the icon to the right of the Reply button. It should say "View the map of this thread". Click on it and you'll see the whole thread and you can read any of the messages in that thread.
>>
>>~~Bonnie
>>
>>
>>
>>
>>
>>>Bonnie,
>>>
>>>Thanks for the tip. Unfortunately, I don't have the deluxe account so I can't look at old threads. I am on the cheaper, Zen account that forces/allows me to live in the moment. If you have the time, could you let me know what conclusions you and your discussants drew from that thread?
>>>
>>>Thanks,
>>>
>>>David
>>>
>>>>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