I am starting out on a big new project and before I leap in I wanted to figure out if I could go the heavy-duty .NET for doing this or if I should roll my own solution to maintain some semblence of control and understanding in my code.
Here is what I need to do:
I have n number of tables in SqlServer that I need to display inside of Windows forms so that the users can view, delete, update and add new records to. Some of these tables have upwards of 50 fields in them. And some will be changing periodically (new fields, dropped fields).
What I want to do is write code to dynamically query the table collection, determine the fields with data type, map those to specific kinds of controls (bool = checkbox), dynamically lay them out inside of a panel on a form so that they look acceptable, name them something logical so I can pull values that have changed, detected changes, serialize those changes back to the db in the form of insert or update commands.
I started doing this with a DataSource pointing at my Sql table. Then I dragged each field onto the form and .NET magically knows the data type and puts a datepicker where I had a date field, awesome. it even changed the labels on my form so that ThisField became This Field in the label. sweet.
I like all of this but its design-time stuff. It wont pick up changes in my data schema like an added field. Is there a way to get this to be more responsive runtime?
The other thing I dont like about it is that I really can get at/understand all of the sql that is going on behind the scenes. Maybe its there and I dont know how to get/read it. But what if I want to update one of the fields that I chose not to show on the form? Can I access that through code or do I put an invisible field on the form?
Anyway, that is the heavy way. If I roll my own I will make a function that will pull all the fields at runtime, test the data type, map to a control, drop the control, space the next control, name it, etc.
I would be doing that myself. I definitely dont want to build the SQL for an update statement to 50 fields so I have to rely on .NET for something.
Anyone doing anything like this? Any suggestions? I think what i want is a happy medium between the two options above. I want .NET to interact with SQL for me at runtime to build a strong types class for me, but then I want to take over.
Here is what I need to do:
I have n number of tables in SqlServer that I need to display inside of Windows forms so that the users can view, delete, update and add new records to. Some of these tables have upwards of 50 fields in them. And some will be changing periodically (new fields, dropped fields).
What I want to do is write code to dynamically query the table collection, determine the fields with data type, map those to specific kinds of controls (bool = checkbox), dynamically lay them out inside of a panel on a form so that they look acceptable, name them something logical so I can pull values that have changed, detected changes, serialize those changes back to the db in the form of insert or update commands.
I started doing this with a DataSource pointing at my Sql table. Then I dragged each field onto the form and .NET magically knows the data type and puts a datepicker where I had a date field, awesome. it even changed the labels on my form so that ThisField became This Field in the label. sweet.
I like all of this but its design-time stuff. It wont pick up changes in my data schema like an added field. Is there a way to get this to be more responsive runtime?
The other thing I dont like about it is that I really can get at/understand all of the sql that is going on behind the scenes. Maybe its there and I dont know how to get/read it. But what if I want to update one of the fields that I chose not to show on the form? Can I access that through code or do I put an invisible field on the form?
Anyway, that is the heavy way. If I roll my own I will make a function that will pull all the fields at runtime, test the data type, map to a control, drop the control, space the next control, name it, etc.
I would be doing that myself. I definitely dont want to build the SQL for an update statement to 50 fields so I have to rely on .NET for something.
Anyone doing anything like this? Any suggestions? I think what i want is a happy medium between the two options above. I want .NET to interact with SQL for me at runtime to build a strong types class for me, but then I want to take over.