Loading controls with objects versus recordsets

I'm building a vb.net Forms project that is getting data from a SQL Server
database.

One of the main goals of the project is to be really responsive to events,
such as textbox change events. I have a textbox for searching, a listbox to
display the searched results, and a big textbox (memo) to display the
clicked-results of the listbox item.

My question is: should I load the controls with objects, and therefore store
everything in memory for fast performance, or is SQL Server fast enough to
capture textbox_change events and return recordsets? Or am I asking too much
of SQL Server? Locally, there will be a dedicated MSDE database, so the load
is manageable. The main database is a shared SQL Server db which is
synchronized as needed.

I have had great results loading controls with objects...the performance is
incredible. However, I think that in the future, as the dataset grows, I
might be storing a couple of megs in RAM, so there might be a penalty in the
future. If I use recordsets, I immediately get a performance penalty, but I
have unlimited future growth.

I appreciate any feedback from anyone on this...what your preferences are
and why. thanks

re: Loading controls with objects versus recordsets

mrmagoo wrote:[color=blue]
> I'm building a vb.net Forms project that is getting data from a SQL Server
> database.
>
> One of the main goals of the project is to be really responsive to events,
> such as textbox change events. I have a textbox for searching, a listbox to
> display the searched results, and a big textbox (memo) to display the
> clicked-results of the listbox item.
>
> My question is: should I load the controls with objects, and therefore store
> everything in memory for fast performance, or is SQL Server fast enough to
> capture textbox_change events and return recordsets? Or am I asking too much
> of SQL Server? Locally, there will be a dedicated MSDE database, so the load
> is manageable. The main database is a shared SQL Server db which is
> synchronized as needed.
>
> I have had great results loading controls with objects...the performance is
> incredible. However, I think that in the future, as the dataset grows, I
> might be storing a couple of megs in RAM, so there might be a penalty in the
> future. If I use recordsets, I immediately get a performance penalty, but I
> have unlimited future growth.
>
> I appreciate any feedback from anyone on this...what your preferences are
> and why. thanks
>
>
>[/color]

You are not thinking about it correctly. if you are loading controls
from objects or directly from SQL the data still has to come from SQL at
some point. Now if you are talking about bringing all the data down and
storing it locally, that will always be fastest.

Chris

re: Loading controls with objects versus recordsets

It's correct.

Depending on the design, there are 2 general possibilities. (or more if you
can think of a better way).

If this is an object based approach, launching the application returns a
recordset and loads all of that into memory. From that point on, the events
load controls from memory.

If this is all recordsets, launching the application does nothing. Typing in
the controls returns small recordsets of matched results for each keystroke.

Does that make sense? At some intervals there will always be recordsets. For
the memory based approach, it occurs on app launch and other intervals as
needed. Perhaps there will be a "refresh" command button that will re-load
all of the objects from the same event that loaded the recordset on app
launch.

For the recordset approach recordsets occur a lot more frequently.


"Chris" <no@spam.com> wrote in message
news:ung2hd0aGHA.4060@TK2MSFTNGP02.phx.gbl...[color=blue]
> mrmagoo wrote:[color=green]
> > I'm building a vb.net Forms project that is getting data from a SQL[/color][/color]
Server[color=blue][color=green]
> > database.
> >
> > One of the main goals of the project is to be really responsive to[/color][/color]
events,[color=blue][color=green]
> > such as textbox change events. I have a textbox for searching, a listbox[/color][/color]
to[color=blue][color=green]
> > display the searched results, and a big textbox (memo) to display the
> > clicked-results of the listbox item.
> >
> > My question is: should I load the controls with objects, and therefore[/color][/color]
store[color=blue][color=green]
> > everything in memory for fast performance, or is SQL Server fast enough[/color][/color]
to[color=blue][color=green]
> > capture textbox_change events and return recordsets? Or am I asking too[/color][/color]
much[color=blue][color=green]
> > of SQL Server? Locally, there will be a dedicated MSDE database, so the[/color][/color]
load[color=blue][color=green]
> > is manageable. The main database is a shared SQL Server db which is
> > synchronized as needed.
> >
> > I have had great results loading controls with objects...the performance[/color][/color]
is[color=blue][color=green]
> > incredible. However, I think that in the future, as the dataset grows, I
> > might be storing a couple of megs in RAM, so there might be a penalty in[/color][/color]
the[color=blue][color=green]
> > future. If I use recordsets, I immediately get a performance penalty,[/color][/color]
but I[color=blue][color=green]
> > have unlimited future growth.
> >
> > I appreciate any feedback from anyone on this...what your preferences[/color][/color]
are[color=blue][color=green]
> > and why. thanks
> >
> >
> >[/color]
>
> You are not thinking about it correctly. if you are loading controls
> from objects or directly from SQL the data still has to come from SQL at
> some point. Now if you are talking about bringing all the data down and
> storing it locally, that will always be fastest.
>
> Chris[/color]

re: Loading controls with objects versus recordsets

mrmagoo wrote:[color=blue]
> It's correct.
>
> Depending on the design, there are 2 general possibilities. (or more if you
> can think of a better way).
>
> If this is an object based approach, launching the application returns a
> recordset and loads all of that into memory. From that point on, the events
> load controls from memory.
>
> If this is all recordsets, launching the application does nothing. Typing in
> the controls returns small recordsets of matched results for each keystroke.
>
> Does that make sense? At some intervals there will always be recordsets. For
> the memory based approach, it occurs on app launch and other intervals as
> needed. Perhaps there will be a "refresh" command button that will re-load
> all of the objects from the same event that loaded the recordset on app
> launch.
>
> For the recordset approach recordsets occur a lot more frequently.
>
>
> "Chris" <no@spam.com> wrote in message
> news:ung2hd0aGHA.4060@TK2MSFTNGP02.phx.gbl...
>[color=green]
>>mrmagoo wrote:
>>[color=darkred]
>>>I'm building a vb.net Forms project that is getting data from a SQL[/color][/color]
>
> Server
>[color=green][color=darkred]
>>>database.
>>>
>>>One of the main goals of the project is to be really responsive to[/color][/color]
>
> events,
>[color=green][color=darkred]
>>>such as textbox change events. I have a textbox for searching, a listbox[/color][/color]
>
> to
>[color=green][color=darkred]
>>>display the searched results, and a big textbox (memo) to display the
>>>clicked-results of the listbox item.
>>>
>>>My question is: should I load the controls with objects, and therefore[/color][/color]
>
> store
>[color=green][color=darkred]
>>>everything in memory for fast performance, or is SQL Server fast enough[/color][/color]
>
> to
>[color=green][color=darkred]
>>>capture textbox_change events and return recordsets? Or am I asking too[/color][/color]
>
> much
>[color=green][color=darkred]
>>>of SQL Server? Locally, there will be a dedicated MSDE database, so the[/color][/color]
>
> load
>[color=green][color=darkred]
>>>is manageable. The main database is a shared SQL Server db which is
>>>synchronized as needed.
>>>
>>>I have had great results loading controls with objects...the performance[/color][/color]
>
> is
>[color=green][color=darkred]
>>>incredible. However, I think that in the future, as the dataset grows, I
>>>might be storing a couple of megs in RAM, so there might be a penalty in[/color][/color]
>
> the
>[color=green][color=darkred]
>>>future. If I use recordsets, I immediately get a performance penalty,[/color][/color]
>
> but I
>[color=green][color=darkred]
>>>have unlimited future growth.
>>>
>>>I appreciate any feedback from anyone on this...what your preferences[/color][/color]
>
> are
>[color=green][color=darkred]
>>>and why. thanks
>>>
>>>
>>>[/color]
>>
>>You are not thinking about it correctly. if you are loading controls
>>from objects or directly from SQL the data still has to come from SQL at
>>some point. Now if you are talking about bringing all the data down and
>>storing it locally, that will always be fastest.
>>
>>Chris[/color]
>
>
>[/color]

It all depends on the size of your dataset and what the client computer
specs would be. No general way is correct.

Chris

re: Loading controls with objects versus recordsets

Mr Magoo,

It depends all from the style from your query box and the ammount of data.

Probably a recordset will not help you much to get speed, because the
datatable is much faster to retrieve and to access. Your program will as
well be needless large because the extra memory you will have to use to hold
the ADODB DLL.

I would just start with creating a query for SQL and return the answer with
an executeScalar.

Just my thought,

Cor



"mrmagoo" <-> schreef in bericht
news:uLaBwT0aGHA.4116@TK2MSFTNGP05.phx.gbl...[color=blue]
> I'm building a vb.net Forms project that is getting data from a SQL Server
> database.
>
> One of the main goals of the project is to be really responsive to events,
> such as textbox change events. I have a textbox for searching, a listbox
> to
> display the searched results, and a big textbox (memo) to display the
> clicked-results of the listbox item.
>
> My question is: should I load the controls with objects, and therefore
> store
> everything in memory for fast performance, or is SQL Server fast enough to
> capture textbox_change events and return recordsets? Or am I asking too
> much
> of SQL Server? Locally, there will be a dedicated MSDE database, so the
> load
> is manageable. The main database is a shared SQL Server db which is
> synchronized as needed.
>
> I have had great results loading controls with objects...the performance
> is
> incredible. However, I think that in the future, as the dataset grows, I
> might be storing a couple of megs in RAM, so there might be a penalty in
> the
> future. If I use recordsets, I immediately get a performance penalty, but
> I
> have unlimited future growth.
>
> I appreciate any feedback from anyone on this...what your preferences are
> and why. thanks
>
>
>[/color]