Re: GetRows Method
From: Al Reid (areidjr_at_reidDASHhome.com)
Date: 06/16/04
- Next message: Jane Ransom: "Re: Reading a MF Cobol file"
- Previous message: Darwin Weyh: "why does a 'select *..." take less time then a 'select <fieldname>...' to update?"
- In reply to: Paul: "Re: GetRows Method"
- Next in thread: Paul: "Re: GetRows Method"
- Reply: Paul: "Re: GetRows Method"
- Reply: Sean Roe: "Re: GetRows Method"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 16 Jun 2004 16:10:10 -0400
Hey Paul, can you spell looser?
I don't see anyone else rushing to help you. Rather than be thankful for
some feedback, you become abusive.
BTW, you sure had a lot to say for someone that didn't wand to carry on a
conversation with me. DUH is not such a harsh reply. I say DUH to myself.
But your skin is too thin and you don't get out much. Too bad.
Come back when you grow up a little and aren't so easily insulted.
"Paul" <NO_SPAM_paul@gotheta.com> wrote in message
news:OH94BW9UEHA.544@TK2MSFTNGP11.phx.gbl...
> Hey dude....are you blind? I told you that i dont want your help. Didn't
> you read that part? Or was it that you did not think through that on your
> own? Or do you insist on being childish and respond to everything I
> write......after I asked you to not write me back. If you are looking for
> the mere satisfaction of winning the argument....then dude....YOU WON! I
> don't know anything about GetRows....but that is why I posted here......I
> did not post here to have someone talk down to me like they are the god of
> programmers. I simply wanted intellgent answers from intellgent people.
I
> recieved neither so far.
> For what it is worth, there were tidbits of knowledge in there that you
> could have written in a response that did not include things like "DUH!".
> It is a good thing MS doesn't say "DUH!" in their documention about ADO or
> we might all be screwed. Seriously man.......it started off as a pretty
> simple subject. Why did you have to turn it into this whole "DUH!"
> thing.....I posted here because I did not know the answer to all of this.
> If i did know, i would not have posted. I guess people like you just dont
> make any sense to me. I asked a reasonable question and you give me a
"DUH"
> answer. I assume you do not do business with people like that, if you are
a
> programmer. So why me? Because you like to feel good about yourself? I
> am a guy has little knowledge about a subject, and i am trying to learn.
> You prey on that with dumb comments because you know more than me about
the
> subject. But i just think it is an insecurity. Because normally people
> with a lot of knowledge about a subject are not insulting because they are
> confident and want to help others.
> But again man.....please dont respond.......I give up with you....you
can't
> seem to help me get the answer i am looking for. You would rather turn
this
> into a battle about how i dont know the answer and not being able to think
> for myself, etc.....which is actually pretty funny because I though enough
> about your answer to realize that you did not think enough about my
question
> to answer it in an intellegent way.
> So dude....don't respond. I DONT WANT YOUR HELP!!!!!!!!!!!!!!!! To post
> here again will show that you just want to play childish games. I dont
know
> how to make it any clearer.....if you aren't going to help me then dont
> friggin post dude!
>
> "Al Reid" <areidjr@reidDASHhome.com> wrote in message
> news:%23HBpiq8UEHA.384@TK2MSFTNGP10.phx.gbl...
> > Hey Dude! If you are so freaking smart, why post to a newsgroup ( not a
> message board).
> >
> > "Paul" <NO_SPAM_paul@gotheta.com> wrote in message
> news:%234T9LS8UEHA.2988@TK2MSFTNGP10.phx.gbl...
> > > I hope you feel so good about yourself man. You have got to be so
proud
> for
> > > writing in such a demeaning way. I mean, a guy writes on a message
> board
> > > and is trying to learn something, and then you try and insult him.
> Hooray
> > > for you man! Hooray!
> >
> > My we are touchy aren't we. You ask a wuestion in a public place and
> dont't like the answer so you cry. Too bad.
> > >
> > > You win dude. You got me and you got me soooo good. You must be so
> proud
> > > of yourself. Oh man, I have got to be the dumbest programmer in the
> world.
> > > Thanks for playing!
> > >
> > > Dude....please quit replying to this thread. I don't want your help
> man.
> > > You are a jack*ss.
> >
> > I guess you are better at name calling than I am. I hope you feel
better
> now. Search the group archive, you will find that I am
> > more than helpful 99% of the time. Not my fault you are so thin skinned
> that a simple DUH sut you off.
> > >
> > > Thanks for nothing. You did nothing to answer my question in an
> intelligent
> > > and articulate manner. You only made meager attempts to insult my
> > > intelligence. And as for your remarks about doing one thing and doing
> two
> > > things. I think you probably ought to research this subject a little
> more.
> > > GetRows pulls back no MetaData (David Sceppa, "Programming ADO"),
> whereas a
> > > recordset does. So it is an apples and oranges thing....you can't say
> "one
> > > step vs. two step". There is much more to it than that.
> >
> > You are correct, there is mush more than that. When you execute the
open
> statement, ADO does not know that you will foollow it with
> > a GetRows. Therefore the time to execute the Open is constant in both
> scenarios. You then add another method call that does what?
> > It moves the data from the recordset to the aV() array, correct? It
takes
> longer, no surprise. Not an insult, just a fact.
> > >
> > > And just so you can see what I am talking about, how about this
article:
> > > http://www.sql-server-performance.com/visual_basic_performance.asp
Go
> down
> > > to the section on GetRows. It says nothing about processing the data.
> It
> > > merely mentions the return of the data. The place that first read
this
> > > information was in "Inside Visual Basic" journal. However, I have no
> online
> > > material for the journal. But there are two sources that I can
quickly
> come
> > > up with. And neither of them mention the processing of the data.
> > >
> >
> > The article stated "The GetRows method is used to pull all the records
> from the recordset into an array." This is done after
> > opening the recordset. The usual purpose of opening a recordset is to
> process data. The GetRows method processed data by filling
> > an array. The Open method, called in both scenarios, does not process
> data so your timing study should be modified as follows:
> >
> > rs.Open
> > ' The rs is open now lets do something with the data
> > oTimer.StartCounter
> > oTimer.StopCounter
> > Debug.Print "Recordset Call: " & oTimer.Elapsed
> >
> > rs.Close
> >
> > rs.Open
> > ' The rs is open now lets do something with the data
> > oTimer.StartCounter
> > aV = rs.GetRows()
> > oTimer.StopCounter
> > Debug.Print "GetRows Call: " & oTimer.Elapsed
> >
> > Do these results surprise you?
> >
> > BTW, dude, don't bother to respond to this since you are incapable of
> accepting an answer to your question or thinking through a
> > problem on your own.
> >
> > Good Luck.
> >
> > >
> > >
> > > "Al Reid" <areidjr@reidDASHhome.com> wrote in message
> > > news:u58MND8UEHA.2716@tk2msftngp13.phx.gbl...
> > > > You really must be kidding! You really think you can open a
recordset
> and
> > > do nothing with it and be surprised that after opening a
> > > > recordset and executing the GetRows method takes longer.
> > > >
> > > > Ok, let me answer it this way...
> > > >
> > > > In both code segments you executed the Open method on a recordset.
> That
> > > causes the SQL to be executed and returns a populated
> > > > recordset. This is what you timed wit the first segment. You did
not
> use
> > > the data in any way. In the second test you executed the
> > > > GetRows method against the recordset. Common sense alone would
> suggest
> > > that it will take longer to execute two methods (all else
> > > > being equal) than one against the recordset object.
> > > >
> > > > I don't know any other way to say it but...DUH! What a surprise.
> > > >
> > > > However, If you wait long enough, someone will surely lead you in
> another
> > > direction.
> > > >
> > > >
> > > > "Paul" <NO_SPAM_paul@gotheta.com> wrote in message
> > > news:uN4VLf7UEHA.1656@TK2MSFTNGP09.phx.gbl...
> > > > > Come on man....no need to be a freakin' jerk off about it.
Message
> > > Boards
> > > > > are not for trying to make people feel stupid. Is this where I
> should
> > > > > insert the word "DUH!"???
> > > > >
> > > > Someone needed to slap you back into reality. Do one operation and
> get
> > > one time, do two and get a longer time. No surprise here.
> > > >
> > > > > I guess you must be reading different articles that I am. The
> articles
> > > that
> > > > > I have read suggest using GetRows instead of a Recordset. They
> suggest
> > > > > using it and accessing something in the variant array. They say
> nothing
> > > > > about building a variant array using a recordset.
> > > >
> > > > I don't need to read anything to knoW that it takes longer to do
> > > something with data than to do nothing with the data.
> > > >
> > > >
> > > > > Why would anyone fill in a variant array with a recordset? None
of
> the
> > > > > articles I have read suggest that this is the alternative. The
> > > suggestion
> > > > > is that the actual call and return is quicker.
> > > > >
> > > > Quicker that what? A loop like..
> > > >
> > > > Do Until rs.EOF
> > > > 'Access the data in the Fields
> > > > rs.MoveNext
> > > > Loop
> > > >
> > > > I am sure that the article you read did not suggest that is was
faster
> > > that doing nothing with the data. If so, post a link to the
> > > > article. Perhaps there was some reading between the lines required.
> > > >
> > > > > If you can't reply without being a jerk then please don't reply.
> The
> > > > > "Well....DUH!" comments are absolutely uncalled for man.
> > > > >
> > > >
> > > > I think they were. Spend a little time looking at your example and
> the
> > > results of your timing test will become so clear that even
> > > > you will proclaim "DUH!"
> > > >
> > > > --
> > > > Al Reid
> > > >
> > > > "It ain't what you don't know that gets you into trouble. It's what
> you
> > > know
> > > > for sure that just ain't so." --- Mark Twain
> > > >
> > > >
> > > > >
> > > > >
> > > > > "Al Reid" <areidjr@reidDASHhome.com> wrote in message
> > > > > news:%231LLBM7UEHA.584@TK2MSFTNGP09.phx.gbl...
> > > > > > So you are saying that it takes longer to execute a GetRows
after
> > > opening
> > > > > the recordset than it is to do nothing at all after
> > > > > > opening the recordset?
> > > > > >
> > > > > > Well..DUH! What did you expect. Add to the code to first
section
> to
> > > loop
> > > > > thru the recordset and build the aV() array and time it
> > > > > > again.
> > > > > >
> > > > > > --
> > > > > > Al Reid
> > > > > >
> > > > > > "It ain't what you don't know that gets you into trouble. It's
> what
> > > you
> > > > > know
> > > > > > for sure that just ain't so." --- Mark Twain
> > > > > >
> > > > > > "Paul" <NO_SPAM_paul@gotheta.com> wrote in message
> > > > > news:u3Yf%23D7UEHA.3664@TK2MSFTNGP12.phx.gbl...
> > > > > > > Hi,
> > > > > > > I was doing some experimentation with the GetRows method.
> > > > > > >
> > > > > > > I have read in a couple of differnet places that GetRows is
> faster
> > > than
> > > > > > > using a recordset. Well, it seems that I am not getting
results
> > > that
> > > > > > > reflect these claims.
> > > > > > >
> > > > > > > Here is a list of my code:
> > > > > > >
> > > > > > > '*******************************************************
> > > > > > > Dim oTimer As CTimeCounter
> > > > > > > Set oTimer = New CTimeCounter
> > > > > > > Dim cnADO As ADODB.Connection
> > > > > > >
> > > > > > > Set cnADO = New ADODB.Connection
> > > > > > > cnADO.ConnectionString = _
> > > > > > > "Provider=SQLOLEDB.1;Persist Security
> Info=False;User
> > > > > > > ID=sa;Initial Catalog=data;Data Source=my-server
> > > > > > > cnADO.ConnectionTimeout = 30
> > > > > > > cnADO.CommandTimeout = 300
> > > > > > > cnADO.CursorLocation = adUseClient
> > > > > > > cnADO.Open
> > > > > > >
> > > > > > > Dim rs As ADODB.Recordset
> > > > > > > Dim aV() As Variant
> > > > > > > Dim aStr As String
> > > > > > > Dim sSQL As String
> > > > > > >
> > > > > > >
> > > > > > > 'sSQL = "SELECT Details.Pressure AS Expr1, Master.Status
AS
> > > Expr2,
> > > > > > > DataHistory.Value AS Expr3, History.Description AS Expr4
FROM
> > > > > DataHistory
> > > > > > > INNER JOIN Details ON DataHistory.NodeID = Details.NodeID
> INNER
> > > JOIN
> > > > > > > 'History ON Details.NodeID = History.NodeID INNER JOIN
> Master
> > > ON
> > > > > > > Details.NodeID = Master.NodeID"
> > > > > > > sSQL = "SELECT * FROM DataHistory"
> > > > > > >
> > > > > > > Set rs = New ADODB.Recordset
> > > > > > > rs.Source = sSQL
> > > > > > > rs.ActiveConnection = cnADO
> > > > > > > rs.CursorType = adOpenForwardOnly
> > > > > > > rs.LockType = adLockReadOnly
> > > > > > >
> > > > > > > oTimer.StartCounter
> > > > > > > rs.Open
> > > > > > > oTimer.StopCounter
> > > > > > > Debug.Print "Recordset Call: " & oTimer.Elapsed
> > > > > > >
> > > > > > > rs.Close
> > > > > > >
> > > > > > > oTimer.StartCounter
> > > > > > > rs.Open
> > > > > > > aV = rs.GetRows()
> > > > > > > oTimer.StopCounter
> > > > > > > Debug.Print "GetRows Call: " & oTimer.Elapsed
> > > > > > >
> > > > > > > rs.Close
> > > > > > >
> > > > > > > '*******************************************************
> > > > > > >
> > > > > > >
> > > > > > > The results were:
> > > > > > >
> > > > > > > Recordset Call: 7145
> > > > > > > GetRows Call: 9173
> > > > > > >
> > > > > >
> > > > >
> > >
>
> --------------------------------------------------------------------------
> > > > > --
> > > > > > > ---
> > > > > > > These results were consistent. GetRows always takes longer.
> The
> > > Sql
> > > > > > > statement that is comment out took 35 seconds to return for a
> > > RecordSet
> > > > > and
> > > > > > > GetRows did not return after about 2 minutes, so i stopped it.
> > > > > > >
> > > > > > > So, the QUESTION is: What am I doing wrong? Why isnt GetRows
> > > quicker?
> > > > > Why
> > > > > > > do people say it is quicker?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Paul
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
- Next message: Jane Ransom: "Re: Reading a MF Cobol file"
- Previous message: Darwin Weyh: "why does a 'select *..." take less time then a 'select <fieldname>...' to update?"
- In reply to: Paul: "Re: GetRows Method"
- Next in thread: Paul: "Re: GetRows Method"
- Reply: Paul: "Re: GetRows Method"
- Reply: Sean Roe: "Re: GetRows Method"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
