How to determine what classes might be necessary for a C# Windows Form App ---> after all controls are added to the Form1 class.

I guess it depends upon you. I'm not sure what you mean by DLL contains connect code. Is  this DotNet connect code that returns a reader?

You can use Datasets and get a lot of info in them. You can bind those to controls, etc.
Or you can use a datacommands (SQLCommand for SQL Server) and execute those to take action and execute them, getting results as a datareader if you just want to get info and populate things. It depends upon what you need to do and the size of the data. I'd limit how much I got into the Dataset based upon some filtering.  Datasets use command and reader objects under the hood.

Here is a video on working with databases in C#:
http://www.youtube.com/watch?v=h_jI4HTCbU0

In answer to both of your comments (i.e. - the solution is up to me), I don't know what is best (efficient).  This will hopefully come out with a little more discussion.  

As for the dll related to SQL, I am almost certain it handles datacommands.  I'm away from the office right now otherwise, I'd verify.  I don't think I am constained to use this if I don't want to.  Also, four out of the six tabs use a datagrid for whatever that's worth.

Maybe the most important consideration is that the user can view, create, delete or modify a customer record.  Also, since the legacy Delphi application appears to have used the Entity Framework how does this influence your approach to the best solution?  I'm under the impression that although the database may accomodate the Entity Framework, an application isn't required to use it, right?

At any rate, I imagine there has to be a 'best' or 'more approved' method to store data in runtime memory until the user commits or submits the record.  

So the question is - if the application only presented data for viewing, then it might not matter too much what approach was used as long as there wasn't any lag time or delays to load the data.  On the other hand, for creating, deleting and modifying customer records with numerous elements, wouldn't that eliminate some alternatives immediately and leave only a preferred method?

Thank you very much!

One method to store data local is by the use of DataSets. You can store a considerable amount in them. Again that depends upon the size of your database.  If it is any size at all you don't want to store it all, but rather to just grab some records, let the user manipulate them and then sync them up with the database.  If it isn't going to have a lot of data or a lot of users aren't going to use it simultaneously then why store it locally?  You could just use commands and data readers.

You can glean some information on using DataReaders from an article I wrote some time ago on Visual Interface Inheritance:

http://www.codeproject.com/Articles/6455/A-Visually-Inheritable-Unbound-Dataform

SStory,

I read through the article.  I downloaded the files but it doesn't appear there is a VB project/solution file.  I used the File menu option to create project from existing code.  Can you add any clarification that will allow me to compile this project.  I posted this question here:

https://www.experts-exchange.com/questions/28178457/How-to-create-and-compile-a-project-using-the-VS-2008-menu-File-New-Project-From-Existing-Code.html

Thanks

John, I did so in your other thread.  Take in mind that project was made and is in use. it was made to do Visual Form Inheritance. I made it to have a simple data entry form that knew how to do 70-80% of the work for me in recreating the same CRUD forms. I only had to inherit the form, override a few methods for whatever differed and I'd have a working CRUD form, complete with error checking, error notification, etc. I only had to think through the logic one time. I did this because at the time although there were lots of tools for doing it with DataSets, etc, there was almost nothing to help with simple commands and datareaders.  

HTH,

Shane

I felt your project would help me to warm up to the SQL and performing record UPDATEs, DELETEs, CREATE, etc.  I also felt it would help me to determine if commands are part of my solution and datasets would handle the datagrids.  I don't know if I have to go one way or the other yet.

My concern is for storing necessary data up until the transaction is complete.  I'm not certain whether fields from multiple tabs could be included but my guess is yes.  This is why I would imagine that I need a class object to store multiple tab data

As for the Inheritance you mentioned, I don't know if this applies.  

CodeCruiser any thoughts here?  How about that Entity Frame Work stuff?  I've done some reading but I still don't know what constitutes a need for such.

Thanks both of you!

I've actually never used the Entity Framework in Dotnet so I'd defer to someone else to speak to that.  Obviously there are several ways of doing things.

You could probably make classes that get persisted to some database. I haven't done it.
I don't really know what your app does or how much data needs to be stored locally. If it is minimal, I might consider storing it all locally, but if you are talking 100K records or millions or higher, I'd let it fetch as needed and hold locally if I wanted to do it that way.  Example, person filters by ID, clicks Fetch or whatever button, the dataset and thus grid is populated with rows matching ID only and possibly a limit of N number of rows if need be.  The fact is a person can only look at so many rows at a time anyway.  If it fetched in this manner and you have 1000's of PC's doing it, it will scale and not bog down.  Now if you are only going to have a handfull--ever--then this is overkill. For a simple app you might just load the grid, when they click on row, show a form with current data, have an update button they click that immediately hits the DB and you are done.  You will have to decide this based upon the nature of your app and the number of rows of data and the expected number of PCs/Users/Load that you will have accordingly.  These are the things I'd consider.

I think you can even persist the XML of datasets locally...so if this is a traveling salesman and he turns off his computer after each stop, the app could persist to XML, then reload that XML to DataSets when opened again. He'd first download info that would be needed for the next few clients, work them (assuming Internet not available) and then reconnect when possible and sync.  All of this of course requires more work so do what you need for your app and in my opinion, don't do it the hard and complex way if it is a simple app, with small number of users/PCs connecting and small amount of data.

Ok great.  Thanks for the angles!  I think the dataset approach will be fine.  Appreciate the articles!