Huge form with data binding

  • Thread starter Thread starter amanatio
  • Start date Start date
A

amanatio

I have a huge form with many data bound controls on it and 34 tables in
database (and of course 34 data adapters and 34 datasets). The form is
extremely slow to design (huge delay when I go to code from design mode
or vice versa) and to show.

I didn't design the form but I WILL redisgn it from scratch. What would
you propose me to do? The form now haw a tab control with 7 tabs and
about 600 text boxes that are bounded to 34 datasets...

Having one dataset with 34 tables instead of 34 datasets is faster? Is
there any catch using data bind in .NET? What is the best practice for
data binding? Any example form with data bind (addnew, load data) ...

Thanks
 
amanatio,

Having one dataset might be easier, but you would be incuring a good
amount of overhead if you arent using all of the tables. The data binding
story doesn't change, you just have to make sure you indicate the table you
want to data bind to when performing the binding (which shouldn't change
things at all).

Other than that, most everything will remain the same (the number of
data adapters, primarily).

You might want to consider whether or not the UI is really a good idea,
as it seems pretty crowded and a lot to go through. Maybe there is a way to
make the operation easier which will in turn allow you to break down the
components and split some things apart?

Hope this helps.
 
Thanks Nicholas,

the form is a 4 pages tax-document. The requirements are that user can
fill all the data on form (we have scanned the document and set the
pictures as background on the form) and make calculations on the from.
So we have to get all document data into datasets for making the
calculations.... Should we use a component class to store all the data
adapters? Perhaps this would make design time faster ...
 
amanatio,

Well, I don't know that placing all the data adapters in another class
is going to help. In the end, it's a good amount of data adapters to be
carrying around.

Separating it out into another component will help with maintinence, at
the least, and I would recommend it. However, in the end, the sheer size of
everything is what is going to give you problems, IMO.

The only other suggestion I can make is to make sure all of your
commands are stored procedures, that way, you can move some of the adapter
code (you won't have to actually have SQL embedded in your code) out of the
app itself.
 
I would really think about my architecture. Since the fom refers to many
tables, can it be split up into multiple forms and use a "wizard" style
layout? The users could be overwhelmed with the sheer amount of information.

I assume that you using a Windows form ? I would also think about building a
"lightweight" data class instead of the dataset to hold my data. Instead of
using data adaptors, you could use Data Readers to populate your data class
and use stored procedures to update your database. There will at least give
you some performance advantages.

Also group the information logically, based on the data the user needs, and
you could span a data class across multiple tables. Storing your data in a
logical data class instead of joing several datasets will save you memory.

Another way you could speed up data access is by setting the right indexes
on your tables but that, of course will be particular to your situation.

Hope that helps
Shane Sukul

Architect
|MCSD||MCAD|
Ashlen Consulting Services
 
Thanks everybody.

I think that redisigning the whole thing with 8 forms rather than 1
form with 8 tabs is top priority...
 
Back
Top