New Financial Suite Inquiry

Hello all........ I've recently been writting a MDI Application in VB.NET. Due to the lacking resources to the new language standards I'm considering changing the application language to C# as I've found tons of resources to this language. What I'm doing is writting a MDI Application that will consist of lots of child windows forms. I will have a specific area to which the child form will load to and the user would be able to have more than one child window open at a time. I will need for the forms not to minimize when a child window is closed (I think this consists of focuse to the individual forms but not sure). It will consist of Inventory managment, customer management, banking managment, vendor management, employee managment, reports and more. I have one primary question to start with here for the application. When linking to ado.net for lets say "ItemList" which consists of the full inventory list I would have groups and then items that fall under those groups. Would it be easier to use a treeview control versus just a dataset view so that the information would be separated into Parent Nodes / Child Nodes? Also currently the specific SQL Table I'm speaking of has over 8500 records to it. In vb.net upon loading the form with a auto data load command within it the form takes between 3-5 minutes to load. The application is unusable till the form/data has been loaded. Would this be a task for multi-threading to speed up the load process of such large amounts of data? I only predict it to get worse as my client currently has a total of over 15,000 products to his company that he would need housed within this one table. Thanks for all your help / feedback to this response. David Watson

Sounds like an ambitious project. However some of the ideas you mentioned puzzle me a bit. Are you trying to load *all* detailed data into local memory? For your first question (tree view VS dataset), it really depends on what your goals/style is. If you want to link your fields directly to your database (so every minute change gets updated immediately) then you will want a dataset. However if you don't mind updating records in batch (even if you only update 1 record at a time) then a tree view would suffice (personally I like tree views and dis-connected recordsets, that way I don't rely on my database to provide the only data validation). For your second question about multi-threading, my stand on multi-threading is that it is *always* a good idea. I multi-thread whereever possible. Sometimes I don't see a performance gain, sometimes I even take a small performance hit, but consequently I always have a good separation of display/business logic/persist logic/data layers. Overall multi-threading has worked very well for me. There are some inherant dangers if you are not careful though, deadlocks and dataracing to name a few. You mentioned that your program takes 3 to 5 minutes to load 8,500 records. This seems like an awefully long time. If you have the proper clustered indexes/primary keys/search idexes/foriegn keys 8,500 records should take you no more than 3 to 7 seconds to pull out on a local server, and 12-30 second on a remote server. With the help of a DBA and some database tuning I am able to pull almost 1 million records from a dataset in about 1 minute. This is just a simple query though. If you start ading outter joins and special case where clauses (e.g. TOP N, or FIRST IN, etc) you will really be eating up some time.

1 Reply

Know the answer? Post it — somebody with the same question will find it here.

Administrator23y ago
Sounds like an ambitious project. However some of the ideas you mentioned puzzle me a bit. Are you trying to load *all* detailed data into local memory? For your first question (tree view VS dataset), it really depends on what your goals/style is. If you want to link your fields directly to your database (so every minute change gets updated immediately) then you will want a dataset. However if you don't mind updating records in batch (even if you only update 1 record at a time) then a tree view would suffice (personally I like tree views and dis-connected recordsets, that way I don't rely on my database to provide the only data validation). For your second question about multi-threading, my stand on multi-threading is that it is *always* a good idea. I multi-thread whereever possible. Sometimes I don't see a performance gain, sometimes I even take a small performance hit, but consequently I always have a good separation of display/business logic/persist logic/data layers. Overall multi-threading has worked very well for me. There are some inherant dangers if you are not careful though, deadlocks and dataracing to name a few. You mentioned that your program takes 3 to 5 minutes to load 8,500 records. This seems like an awefully long time. If you have the proper clustered indexes/primary keys/search idexes/foriegn keys 8,500 records should take you no more than 3 to 7 seconds to pull out on a local server, and 12-30 second on a remote server. With the help of a DBA and some database tuning I am able to pull almost 1 million records from a dataset in about 1 minute. This is just a simple query though. If you start ading outter joins and special case where clauses (e.g. TOP N, or FIRST IN, etc) you will really be eating up some time.
+1