I haven't tried submitting anything, but if it's the 'New Time Card" form, on thing contributing to the problem will be your City / County setup, with the join / CDD elements. They don't seem to be correctly set up, which can cause very significant performance issues.
You are using the "CityName" as the key for the cities table (rather than the 'id'), and the foreign key for the CDD's "watch" setting. Which won't work, as CityName is not unique. How many cities are there called "Madison" in the US, for example? Using non-unique keys leads to all kinds of problems, not least of which is a geometric increase in the number of rows being selected when the main query to build you list runs, especially if you have a lot of table joins, which you do.
The relationship between your "child" and "parent" in a CDD / join relationship eneds to use a unique key - pretty much always the Primary Key on the parent, which means using "normalized" tables. In this case, it means having a "counties" table which has a "city_id" element, which is an FK (foreign key) pointing to the single unique row in the "cities" table it has related data for.
If you think about what a join/CDD pair is doing, you can make sense of it. Lets take an actual "parent" and "child" set up as an example. You have one table for parents, and one for their children. When you select the row for "John Smith" from your parents dropdown, you just want his two children to show on the "child" element's dropdown. You don't want every child whose father is called "John Smith", which is what you get if you use "ParentName" as the key to relate the two. So rather than "ParentName", you need to use 'id' (the primary key of the parents table), so the 'child' CDD knows EXACTLY which "John Smith". Which means having your 'child' table "normalized", using the PK of the parent table as the FK (foreign key), so you have a child.parent_id field in the child table, and use that as the FK.
-- hugh
