Wow, so this is kind of fascinating.
First as to item 3 - the data fields are always going to be in a repeating group. You'll want to drag the /dfs:myFields/dfs:dataFields/d:LU_EMPLOYEE group from the Main data source onto your form. You can set the repeating group properties so that the user can't insert more instances of the repeating group. This data structure is the IP structures a data base bound form, which is what you are creating. Since the table the form is bound to has more than one row in it, IP makes the data fields group repeating.
However, what is really interesting is item 4. You have a second data connection to the very same table, and it seems that IP is very confused by that!
Here is the XPath to your employee name field in your main data source: /dfs:myFields/dfs:dataFields/d:LU_EMPLOYEE/@EMPLOYEE_NAME
Here is the XPath the your employee name field in your secondary data source: /dfs:myFields/dfs:dataFields/d:LU_EMPLOYEE/@EMPLOYEE_NAME
Notice anything? They are the same.... So, my guess would be that InfoPath is having some kind of a fit trying to validate this. I think if what you really want to do is have your list of employees be from the same table where you are submitting, you may need to create a view (in SQL - not sure what the equivalent is in Access - a Query?) and then use that for your secondary data source. I'd give my view a distinctly different name from LU_EMPLOYEE, and I'd also alias my columns in the view (EMPLOYEE_NAME as EMPNAME or something). That way you can be sure that your XPath will be different.
All that being said, it could be you are using the same table for both just as a simple test, and for your actual form you intend to use different tables. If that is the case, I'd suggest setting up your test to more accurately reflect your intended final architecture.