Regarding Enterprise Forms ... the databinding is an option, not a requirement, and is something you could grow into down the road. Here's an example of how I used it: Had a survey-type form with lots of questions and all of the answer options were the same: Strongly Disagree, Disagree, Neutral, Agree, Strongly Agree.
Now I could have created radiobutton responses manually for each question. Or I could put these responses into a database table, name them as a group, and then use a stored procedure (GetOptions('Ngroup")) ... where "Ngroup" is in the GroupName column. Behind the scenes, the stored proc gets these five options and binds them to the radiobutton control. Instead of manually creating the radiobuttonlist for each question, I just enter (GetOptions('Ngroup")) in the databind panel. Quite a time saver.
So yes - this may be a bit over your head at the moment, but see that someday it wouldn't, and that it would become useful. In the meantime, you can roll it all manually just like in Form Master.
Form Master is also develping or has developed the ability to databind. But in both cases it will be optional; you can create the radio buttons right in the form designer in each case.
Regarding work flow in Enterprise Forms - it also is optional - sort of - you can create a non-work flow work flow which is just a simple submit.
The reason I mentioned Enterprise Forms was the indication in the initial post that storing the results of the form submission in an SQL table was desirable. Since Enterprise Forms can do that, I have then been able to use the data in that table for other modules or purposes.
Example: I have some forms that are related but submitted by different players. One is submitted by a student, and dwhen submitted, an email is generated to a guidance counselor who comes to fill out another form ... he or she knows the student's portal ID because it was sent in the email ... and the guidance counselor has to enter it in the form along with other information.
Now I can do a join on the two tables based on the ownerid of the student's form, and the student id of the guidance counselor's form. This is beyond normal reporting needs and beyond what Enterprise Forms can offer, but is possible because the data is in tables.
Having the data in a table isn't necessary only for reporting, as another person pointed out; you can get data from XML fragments into Excel, csv, etc. But there are other things you might want to do with data that isn't strictly pulling out such reports, and that is when it is so handy to have it in a table.
Not trying to over-argue the case for Enterprise Forms, just giving a glimpse at what I've been able to do with it that made me think of it in response to your post.
Form Master is easier to learn, less complex, Steve is very responsive to good feature requests, and it is moving in the direction of including possibilities for work flow as well. There are some things I like better about Form Master, actually. Just had some needs that required the greater complexity of Enterprise Forms. It's always a pleasure to use Form Master, and I've always plugged it when given the opportunity.
Note: Form Master, not Forum Master. I found myself doing the same typo a couple days ago so I had to chuckle when I saw it here. 