After doing a bunch of work with ASP.NET and SQL Server, I'm now starting to
work with C#.NET Windows Forms applications.

So far, the database stuff doesn't seem that impressive to me. We'll see.

I've got a details view setup on a form. It wasn't too much trouble. But I
notice the default behavior seems to be load the entire table, even though
only one record is shown at a time.

For larger tables, this seems horribly efficient, especially since I'm
taking the data from a live Website's database.

Am I the only one who questions this approach? And is changing this behavior
a big deal or are there straight forward ways of making this more efficient?

Thanks.

Jonathan

What is your starting point ? This is perhaps just the wizard default.
Ultimately this is code and there is nothing that prevents to customize this
at will...


--
Patrice


"Jonathan Wood" <(E-Mail Removed)> a écrit dans le message de groupe
de discussion : eSc$(E-Mail Removed)...
> After doing a bunch of work with ASP.NET and SQL Server, I'm now starting
> to work with C#.NET Windows Forms applications.
>
> So far, the database stuff doesn't seem that impressive to me. We'll see.
>
> I've got a details view setup on a form. It wasn't too much trouble. But I
> notice the default behavior seems to be load the entire table, even though
> only one record is shown at a time.
>
> For larger tables, this seems horribly efficient, especially since I'm
> taking the data from a live Website's database.
>
> Am I the only one who questions this approach? And is changing this
> behavior a big deal or are there straight forward ways of making this more
> efficient?
>
> Thanks.
>
> Jonathan
>

My starting point was an empty form, and I created a dataset and dragged it
onto the form.

I know it can be customized. But I'm not clear if the behavior described can
be easily modified, or if I simply have to code the entire thing from
scratch.

Jonathan

"Patrice" <http://scribe-en.blogspot.com/> wrote in message
news:(E-Mail Removed)...
> What is your starting point ? This is perhaps just the wizard default.
> Ultimately this is code and there is nothing that prevents to customize
> this at will...
>
>
> --
> Patrice
>
>
> "Jonathan Wood" <(E-Mail Removed)> a écrit dans le message de groupe
> de discussion : eSc$(E-Mail Removed)...
>> After doing a bunch of work with ASP.NET and SQL Server, I'm now starting
>> to work with C#.NET Windows Forms applications.
>>
>> So far, the database stuff doesn't seem that impressive to me. We'll see.
>>
>> I've got a details view setup on a form. It wasn't too much trouble. But
>> I notice the default behavior seems to be load the entire table, even
>> though only one record is shown at a time.
>>
>> For larger tables, this seems horribly efficient, especially since I'm
>> taking the data from a live Website's database.
>>
>> Am I the only one who questions this approach? And is changing this
>> behavior a big deal or are there straight forward ways of making this
>> more efficient?
>>
>> Thanks.
>>
>> Jonathan
>>
>

I would totally abandon the "drag and drop" approach...aka, the "RAPID"
approach.

You can find an example of using the DAAB 2.0 at:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry

I have an updated version using the EnterpriseLibrary.Data at:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry

However, the second one doesn't have datasets in it. The first one uses the
..LoadDataSet method to populate strong datasets via stored procedures.

........................

In my opininon
RAPID != Good.

Rapid development is very hard to maintain.




"Jonathan Wood" <(E-Mail Removed)> wrote in message
news:eSc$(E-Mail Removed)...
> After doing a bunch of work with ASP.NET and SQL Server, I'm now starting
> to work with C#.NET Windows Forms applications.
>
> So far, the database stuff doesn't seem that impressive to me. We'll see.
>
> I've got a details view setup on a form. It wasn't too much trouble. But I
> notice the default behavior seems to be load the entire table, even though
> only one record is shown at a time.
>
> For larger tables, this seems horribly efficient, especially since I'm
> taking the data from a live Website's database.
>
> Am I the only one who questions this approach? And is changing this
> behavior a big deal or are there straight forward ways of making this more
> efficient?
>
> Thanks.
>
> Jonathan
>

Thanks, I'll check those out. I was mostly wondering what others are doing.

Most of what I've been doing is running a query before opening the form and
running another if I need to save changes. But, for this particular project,
I just kind of need to slop some things together that could take a lot of
time.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
http://www.softcircuits.com/blog/


"sloan" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
>
> I would totally abandon the "drag and drop" approach...aka, the "RAPID"
> approach.
>
> You can find an example of using the DAAB 2.0 at:
> http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry
>
> I have an updated version using the EnterpriseLibrary.Data at:
> http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry
>
> However, the second one doesn't have datasets in it. The first one uses
> the .LoadDataSet method to populate strong datasets via stored procedures.
>
> .......................
>
> In my opininon
> RAPID != Good.
>
> Rapid development is very hard to maintain.
>
>
>
>
> "Jonathan Wood" <(E-Mail Removed)> wrote in message
> news:eSc$(E-Mail Removed)...
>> After doing a bunch of work with ASP.NET and SQL Server, I'm now starting
>> to work with C#.NET Windows Forms applications.
>>
>> So far, the database stuff doesn't seem that impressive to me. We'll see.
>>
>> I've got a details view setup on a form. It wasn't too much trouble. But
>> I notice the default behavior seems to be load the entire table, even
>> though only one record is shown at a time.
>>
>> For larger tables, this seems horribly efficient, especially since I'm
>> taking the data from a live Website's database.
>>
>> Am I the only one who questions this approach? And is changing this
>> behavior a big deal or are there straight forward ways of making this
>> more efficient?
>>
>> Thanks.
>>
>> Jonathan
>>
>
>

This is essentially a personal preference. If you use the dataset designer
you'll see that you can customize the underlying query used to retrieve the
data, add aditionnal ones and even add custom code in a partial (it allows
to keep apart designer generated and developper code) class etc.. .

Try : http://msdn.microsoft.com/en-us/library/314t4see.aspx for details
about the customization hooks...

Before doing so an alternate approach is to provide filtering capabilities.
For large table users generally won't browse the whole table even by small
"pages" of 20 rows. So I would likely add filtering capabilities so that the
user can load the rows he is interested in, would likely display them in a
datagrid for easy browsing before triggering a detail view when needed...

My personal preference is to code but I'm likely showing my age here... Try
and just pick your preferred style. There is no dead end...

--
Patrice


"Jonathan Wood" <(E-Mail Removed)> a écrit dans le message de groupe
de discussion : #(E-Mail Removed)...
> My starting point was an empty form, and I created a dataset and dragged
> it onto the form.
>
> I know it can be customized. But I'm not clear if the behavior described
> can be easily modified, or if I simply have to code the entire thing from
> scratch.
>
> Jonathan
>
> "Patrice" <http://scribe-en.blogspot.com/> wrote in message
> news:(E-Mail Removed)...
>> What is your starting point ? This is perhaps just the wizard default.
>> Ultimately this is code and there is nothing that prevents to customize
>> this at will...
>>
>>
>> --
>> Patrice
>>
>>
>> "Jonathan Wood" <(E-Mail Removed)> a écrit dans le message de
>> groupe de discussion : eSc$(E-Mail Removed)...
>>> After doing a bunch of work with ASP.NET and SQL Server, I'm now
>>> starting to work with C#.NET Windows Forms applications.
>>>
>>> So far, the database stuff doesn't seem that impressive to me. We'll
>>> see.
>>>
>>> I've got a details view setup on a form. It wasn't too much trouble. But
>>> I notice the default behavior seems to be load the entire table, even
>>> though only one record is shown at a time.
>>>
>>> For larger tables, this seems horribly efficient, especially since I'm
>>> taking the data from a live Website's database.
>>>
>>> Am I the only one who questions this approach? And is changing this
>>> behavior a big deal or are there straight forward ways of making this
>>> more efficient?
>>>
>>> Thanks.
>>>
>>> Jonathan
>>>
>>
>

There's nothing wrong with the RAD approach as long as you understand that
the code that is generated can be modified. Those advising against RAD may
be biased because of Microsof't history of generated code, but with Visual
Studio .NET, it's a simple thing to customize this code.

When you create a form with a data control on it (like a Form View), a
DataSource control is also created. Simply right-click that control and
choose to customize and you will be taken, step-by-step through the process
of configuring it.

In your particular situation, where you have a large table, you can ajdust
the SELECT statement to simply pull a certain amount of records, rather than
all of them. Then, upon advancing to the point where more records are
needed, you'd connect again and get the next set.

-Scott


"Jonathan Wood" <(E-Mail Removed)> wrote in message
news:eSc$(E-Mail Removed)...
> After doing a bunch of work with ASP.NET and SQL Server, I'm now starting
> to work with C#.NET Windows Forms applications.
>
> So far, the database stuff doesn't seem that impressive to me. We'll see.
>
> I've got a details view setup on a form. It wasn't too much trouble. But I
> notice the default behavior seems to be load the entire table, even though
> only one record is shown at a time.
>
> For larger tables, this seems horribly efficient, especially since I'm
> taking the data from a live Website's database.
>
> Am I the only one who questions this approach? And is changing this
> behavior a big deal or are there straight forward ways of making this more
> efficient?
>
> Thanks.
>
> Jonathan
>

I agree. I've written quite a bit about how to create optimized code with
the existing Visual Studio tools. While my latest book provides a great deal
of information that you might find useful, perhaps a focused article on
creating TableAdapters would be of more immediate help. See
http://www.sqlmag.com/Article/Articl...ver_97182.html.

--
__________________________________________________________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
http://betav.com http://betav.com/blog/billva
____________________________________________________________________________________________



"Jonathan Wood" <(E-Mail Removed)> wrote in message
news:eSc$(E-Mail Removed)...
> After doing a bunch of work with ASP.NET and SQL Server, I'm now starting
> to work with C#.NET Windows Forms applications.
>
> So far, the database stuff doesn't seem that impressive to me. We'll see.
>
> I've got a details view setup on a form. It wasn't too much trouble. But I
> notice the default behavior seems to be load the entire table, even though
> only one record is shown at a time.
>
> For larger tables, this seems horribly efficient, especially since I'm
> taking the data from a live Website's database.
>
> Am I the only one who questions this approach? And is changing this
> behavior a big deal or are there straight forward ways of making this more
> efficient?
>
> Thanks.
>
> Jonathan
>

"Jonathan Wood" <(E-Mail Removed)> wrote in
news:eSc$(E-Mail Removed):

> After doing a bunch of work with ASP.NET and SQL Server, I'm now
> starting to work with C#.NET Windows Forms applications.
>
> So far, the database stuff doesn't seem that impressive to me. We'll
> see.
>
> I've got a details view setup on a form. It wasn't too much trouble.
> But I notice the default behavior seems to be load the entire table,
> even though only one record is shown at a time.
>
> For larger tables, this seems horribly efficient, especially since I'm
> taking the data from a live Website's database.
>
> Am I the only one who questions this approach? And is changing this
> behavior a big deal or are there straight forward ways of making this
> more efficient?

The drag and drop bits are extremely inefficient for large tables. When
I do this, I will drag and drop to create the controls on the form, as
it is very quick. I then will change the binding to a more sane
approach. If I am using DataSets, I will change the call to the
TableAdapter and bind in code.


--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

"sloan" <(E-Mail Removed)> wrote in
news:#(E-Mail Removed):

>
> I would totally abandon the "drag and drop" approach...aka, the
> "RAPID" approach.

I use the RAPID approach and then scrap the bindings. It helps me build
a form rather quickly, but I then ignore the behind the scenes stuff. I
think of it as throwing out the bathwater and keeping the baby. ;-)

> You can find an example of using the DAAB 2.0 at:
> http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry
>
> I have an updated version using the EnterpriseLibrary.Data at:
> http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry
>
> However, the second one doesn't have datasets in it. The first one
> uses the .LoadDataSet method to populate strong datasets via stored
> procedures.

In general, I would scrap DAAB 2.0, as it is not the latest suggested
approach to data access. The new EntLib is not bad, although I am more
fond of using a Repository approach for data access. When the RIA bits
are released (realizing that RIA means Rich Internet Application and is
not "designed" for windows apps officially - it does work), you should
see some Repository samples. The ASP.NET MVC stuff from Phil Haack has
some bits you can adopt to windows apps that are rather nice.

In the end, DataSets, EF and/or objects are not huge changes, if your
code is properly tiered. You do have to alter the binding a bit, of
course, and you completely change some data access bits, but models are
models ultimately. Once again, design of the app is the key for
switching out bits.

In summary, I see nothing wrong with dragging, creating a form, and then
gutting out what you are not going to use and switching to a more
"sane" data access paradigm. It saves a lot of time doing the rote
"design" work and the baggage is easy enough to kill.


--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************