Connecting Controls Up to Data in/from Multiple Locations

Using Visual Web Developer 2010 and targeting .NET 4.0 (because that's what the book uses that I'm trying to learn all the basics from).
Working in C#.
Trying to see if I can work with Entity Framework.

What is supposed to be the best way to create a form so it can save particular pieces of new submissions into multiple databases? (A new member enters in their personal info, with the physical address being saved to a separate database, to leave open the possibility of adding in more addresses later.) If accurate, I'm finding that .NET will not allow inserting/editing on tables associated as "navigation" properties of the entity. Navigation properties can only be displayed. So far, as a .NET novice, in order to create this form, I'm seeing 3 ways:
A) Create 1 DetailsView control sourced from an entity that represents the table containing the bulk of the form's info; and then, after inserting the new fields that can be, programmatically insert the address fields (probably using a 2nd entity based on the addresses table). I haven't tested this theory yet.
B) Create 3 DetailsView controls - the 1st connected to the main entity; 2nd connected to the addresses entity; and the 3rd connected to the main entity again, set to update by default. (I want/have to make the form in 3 sections in order to maintain some coherency to the order of items requested - name, phone, email; addresses; followed by errata pertaining to the membership.) Then, w/ the controls in place, set up a chain of events to fire after the 1st control inserts - grab the unique id, trigger insert on the 2nd form, and then fire the 3rd to update the member record w/ its info. I tested a truncated version of this, and got it to work; I didn't just run w/ it because I realized the last form would require updating vs inserting. I could hide each subsquent section until the 1st is filled in, and pass info forward.  What a fussy mess.
C) Use an SqlDataSource w/ the DetailsView control, and manually write its INSERT statement. But that requires I don't run into some new roadblock while experimenting. And what's the point of all this fancy-schmancy OOP if I have to manually write out the SQL statement, and create a bunch of templates in the control for each field and bind them all up by hand.

I can't imagine this is that uncommon a process, esp given that this is the whole point of relational databases, and the SQL itself handles such situations with relative aplomb. I've certainly seen plenty asking similar questions, many unanswered, many finding their own answer, for some reason none of them addressing the issue in a way that works for me or seems to really make the situation work as it should.
So my question is: what might be the "normal" or more common way someone w/ better understanding of .NET would put this form together?

Thank you for any clarity anybody can provide for all this.
Who is Participating?
universalgloveConnect With a Mentor Author Commented:
Well, holy #@*^in' hallelujah.

The SqlDataSource worked with no real hitches.
(But, man, the DetailsView is still a gnarly lookin' monster.
Looking like FormView will be the mode for everything except back-end management of anything but the simplest, plainest data.)

(Procedural VBScript doesn't seem quite as cumbersome anymore;
and thoughts of PHP make me happier and happier all the time.
What is the point of all this new-fangled .NET / OOP / IDE shtuff when, in the end, you have to customize and hand-code in a procedural fashion anything that's slightly more complex than "Hello World" anyway, and still use a whole bunch of external tools to determine what's wrong? Why was it not a priority to make something like the Entity Framework handle such complexity? The Entity Model knows how it's all connected already! It knows how it all hooks up. Why can that not be made to handle common, multifaceted operations involving everything it already knows about?)

Now to add validation and styles (and deal with all the weird, limited, humongoloid ID system that Microsoft thought was a good idea. Why are hyphens not allowed in IDs? Why does a control need its parent's ID prepended?)

OK. I'll quit now...
universalgloveAuthor Commented:
OK. Successfully cleared up all the issues around trying to work with all the controls in one form and grab the data back out of the non-bound ones. Now I have to see how easily I can get them into a new "Address" entity. Trying to just create a new "Address" directly, but I still want to see, per my original intention, whether I can use the "Addresses" EntityDataSource to do the heavy lifting, since I went through the trouble of creating one and all, and totally seems like this sort of operation is something that should be accessible in a datasource.
universalgloveAuthor Commented:
I'm quickly (hehe) coming to the conclusion that the only truly workable solution for any degree of complexity is an SqlDataSource, since I can just manually write the freaking SQL I need. Of course, I haven't actually done that yet and am just starting now to try this approach, soooo ... what could possibly go wrong!?

The EntityDataSource.Insert() using the extension to the EntityDataSource controls just isn't working. Acts like it's going to, now that I got past the compile problem, but I can't apparently get any actual data into the properties during the Inserting event. Not working for me, anyway.

So, one DetailsView based on an SQLDataSource coming up next!
universalgloveAuthor Commented:
No. Just glad something worked without 3 days worth of eking out every little possible limitation and thing that could go wrong for something I should think is a pretty common operation.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.