Если по-простому без всяких паттернов, то заводишь класс города (City, напимер), заводишь список городов, байндишь этот список к листбоксу, где для отображения городов в списке выбираешь название города.

Заводишь обработчик в литсбоксе для вызова формы. При вызове формы передаёшь в неё выбранный город, где байндишь поля города на поля формы.

Далее нюансы - если используешь какой-то механизм привязок, то сохраняться всё должно и так. Если всё руками делаешь, то, соответственно, пишешь код, который переводит поля города в поля формы, выводит города в листбокс по их названиям, сохраняет город из формы в список городов и обновляет при этом листбокс.

Вообще, рекомендовал бы сделать всё на WPF и использовать встроенные привязки. Вот самый простой пример для WPF для отображения твоего списка городов. Добавить функциональности для создания и сохранения города - уже надо посложнее пример. Вот такой , например. Только вместо форм - вкладки, что сути не меняет. Вот ещё простой пример твоей тематики, только без отдельной формы для редактирования, а просто в специально области над списком.

https://www.google.ru/search?hl=en-RU&source=hp&biw=&bih=&q=C# wpf child window position&gbv=2&oq=C# wpf child window position&gs_l=heirloom-hp.3..0i22i30l2.1913.11145.0.11297.30.28.1.1.1.0.131.2851.9j19.28.0....0...1ac.1.34.heirloom-hp..0.30.2852.fxYww2X6XAs

http://stackoverflow.com/questions/2446602/wpf-set-dialog-window-position-relative-to-main-window

SAS2014нужно чтобы
SAS2014А надо, чтоб этого не было.
Так нужно или не нужно? ))

В любом случае, вам надо изучить, что такое связи между таблицами и как создавать связи "один к одному", "один ко многим" и "много ко многим". В частности, если у вас ни одни сотрудник не может работать сразу более, чем в одной компании, то достаточно в таблице сотрудников завести поле CompanyID - т. е. идентификатор компании. Тогда каждый сотрудник будет привязан к какой-нибудь компании, причём только к одной.

Doomplay998Тогда каждый сотрудник будет привязан к какой-нибудь компании, причём только к одной.
При этом можно создавать компании с одинаковыми именами, но разными идентификаторами, но сотрудник всё равно будет привязан только к компании с конкретным идентификатором, независимо от её названия.

А вообще, названия компаний тоже следовало бы сделать уникальными - чтобы нельзя было создавать компании с одинаковыми именами. Вроде, в реальном мире одновременно не могут существовать компании с одинаковыми именами. Даже если это холдинг - всё равно мать и все дочки по-разному называются.

SAS2014Doomplay998пропущено...

пропущено...

Так нужно или не нужно? ))


нужно чтобы при создание компании сотрудники уже записаной в БД такой же кампании не попадали в новую

автордостаточно в таблице сотрудников завести поле CompanyID - т. е. идентификатор компании. Тогда каждый сотрудник будет привязан к какой-нибудь компании, причём только к одной.

SAS2014а без создания дополнительных столбцов в табл. сотрудников что ни как, если уже есть столбец с ID компаниями в табл. сотрудники.
На самом деле надо ещё создать так называемое отношение - сущность, которая связывает две таблицы. Я не совсем понял, что вы раньше имели ввиду под "вручную забил ID компании". При отношении есть разные правила - на удаление, добавление, изменение записей и прочие действия. Чтобы СУБД отрабатывала автоматически эти действия, нужно задать эти отношения с правилами. Если таблицы будут без отношений, то вам нужно будет реализовать операции, связанные с изменениями сразу в нескольких таблицах, в самом приложении - т. е. вне базы данных. Такой подход не распространён и не рекомендуется.

Там много ещё каких нюансов есть, которые здесь обсуждать нет смысла - мы же не будет за вас писать вам приложение с нуля на протяжении всей темы на форуме. )))

Такое ощущение, что вы либо не читали ничего про базы данных, либо только первые главы в какой-нибудь книжке прочитали. Советую ознакомиться с этой темой подробнее. Т. е. если у вас какая-то книжка по Аксессу (сам я им не пользовался), то почитайте побольше. Там должна быть общая теория баз данных - что такое таблицы, отношения, нормальные формы (хотя бы первые две, без которых нормальные БД не делаются). Без этого нет смысла что-то дальше обсуждать - вы будете спотыкаться об каждое слово и на каждом шагу делать не так.

И да, в будущем старайтесь создавать отдельные темы по разным вопросам, чтобы эти темы не превращались в персональные обсуждения персональных проблем.

Если надо компании уникальные, но с возможностью одинаковых имён - делаете уникальный идентификатор, а столбец имени делаете неуникальным. В таблице сотруюников заводите поле "идентификатор компании" - не "имя компании". Тогда сотрудник будет привязан к идентификатору компании, а не к её имени.

Естественно , что при выводе всех сотрудников всех компаний с одинаковым именем они будут находиться как бы под одной компанией. Может, в этом у вас проблемы, я понять не могу? Но если так, то это и должно быть . Хотели одинаковые имена для компаний - получили. Требование, чтобы у компаний были одинаковые имена , но их сотрудники были под компаниями с разными именами - немного противоречиво, если вообще не антилогичный бред, не находите? Но если нужна такая идиотия, то и для неё у нас есть некоторый подход - заводите для компаний ещё один столбец что-то вроде DisplayName - имя для показа в интерфейсах и прочих местах, где надо отображать имя компании. Там можно сделать разное отображение - типа "Intel 1", "Intel 2" и т. п. Теперь в таблице компании есть три гланых для нас столбца - "идентификатор", к которому привязываются сотрудники, неуникальное "имя" и уникальное "имя для показа". Но мне сдаётся, что этот бред, будучи явленным вашему начальству, сразу покажет, что "начальник - дурак" и вам скажут всё переделать - сделать уникальные имена для компаний. Впрочем, это не моё дело - я вам предложил возможный подход для реализации бреда.

Ещё раз рекомендую прочитать про базы данных подробнее - многие вещи должны для вас проясниться.