Best Practices for Managing VB.NET Windows Forms apps with Multiple Dynamic Data Tables
Hello Again Experts.
I must apologize in advance for my brevity, but I recently injured my hand in the wood shop, and typing is somewhat difficult.
The situation that I am dealing with right now is that I am very frequently experiencing conflict between changes that I make in my Access tables/queries, and keeping my VB.NET Windows Forms app in sync with these changes. For example, if my program is stable with no DB issues, and I decide that I want to add a new field/column to a given table using Access, when I return to my program, it invariably produces errors related to the changes I make.
Today I made a change to an Access Query which is attached to a DataGridView in which I connected a new table to get a related field value. The Query works fine in Access, but now not only does the program fail to compile because of the DGV association, but the Data Source Configuration Wizard shows what before was a View is now a broken Table!
I'm pretty sure that Visual Studio stores a boatload of data pertaining to my database, and that needs to agree with the MDB file, so I just need to know that correct way to make minor changes to my tables and queries. Ultimately what I'm hoping to accomplish is to find a way to have ONE source for my database definitions, and just have a file (or files) store the data.
I realize this is not a lot to go on, but that's all I can offer for the moment.
Many Thanks,
Tony G.
I must apologize in advance for my brevity, but I recently injured my hand in the wood shop, and typing is somewhat difficult.
The situation that I am dealing with right now is that I am very frequently experiencing conflict between changes that I make in my Access tables/queries, and keeping my VB.NET Windows Forms app in sync with these changes. For example, if my program is stable with no DB issues, and I decide that I want to add a new field/column to a given table using Access, when I return to my program, it invariably produces errors related to the changes I make.
Today I made a change to an Access Query which is attached to a DataGridView in which I connected a new table to get a related field value. The Query works fine in Access, but now not only does the program fail to compile because of the DGV association, but the Data Source Configuration Wizard shows what before was a View is now a broken Table!
I'm pretty sure that Visual Studio stores a boatload of data pertaining to my database, and that needs to agree with the MDB file, so I just need to know that correct way to make minor changes to my tables and queries. Ultimately what I'm hoping to accomplish is to find a way to have ONE source for my database definitions, and just have a file (or files) store the data.
I realize this is not a lot to go on, but that's all I can offer for the moment.
Many Thanks,
Tony G.
Scott McDaniel (EE MVE )
Are you asking how you can update your Datasource in Visual Studio? If so, try selecting the datasource, then right click and select 'Update'. Depending on how your Datagridview is setup, it should pick up the other columns.
ASKER
Thanks for jumping in, Scott. I'm pretty much fed up with MS Access (at least in terms of it being my back-end database for VB.NET development) and very much want to get away from it altogether.
I've downloaded a copy of MySQL in hopes that it will work better, so now my main concern is figuring out how to most easily migrate.
The goal is to learn how to do all my database design using code so I'm not dependent on any front-end software, and also to eliminate the huge overhead associated with using Visual Studio to import my tables. It's certainly easier at first, but having experienced countless hours of fighting wars I now wish that I had learned to do it the "hard way" first.
I've downloaded a copy of MySQL in hopes that it will work better, so now my main concern is figuring out how to most easily migrate.
The goal is to learn how to do all my database design using code so I'm not dependent on any front-end software, and also to eliminate the huge overhead associated with using Visual Studio to import my tables. It's certainly easier at first, but having experienced countless hours of fighting wars I now wish that I had learned to do it the "hard way" first.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.