Sumor

Вы определитесь у вас ListBox или ComboBox.
В заголовке ComboBox, поэтому когда вызывается событие, у вас sender типа ComboBox, а не ListBox к которому вы приводите.

Строчка usersGrid.ItemsSource = db.USER.Local.ToBindingList(); говорит о том, что конкретно этот текущий список записей из таблицы опубликовать в DataGrid. При повторном выполнении Load() у вас создаются новые списки, никак не связанные с тем, что находится сейчас в DataGrid. Поэтому обновления не происходит.
Чтобы понять что изменилось в БД с момента прошлого считывания можно использовать, например, время изменения записи. И каждые 10 (или сколько вы захотите) секунд считывать только изменённые записи.
Просто так изменённые записи в уже считанный и добавленный в грид список не обновить. Нужно найти среди существующих строчек те, что обновились в соответствии с запросом и изменить их реквизиты. Так как вы используете BindingList, то по идее после изменения записи в списке DataGrid должен обновить запись на экране.
Схема может быть примерно такая:
DataGrid на форме привязан (Binding) к один раз созданному списку сообщений типа BindingList<> или ObservableCollection<>. Сообщения, которые хранятся в этом списке должны реализовывать шаблон PropertyChanged. Список первоначально начитывается при старте формы. После создания, заполнения и привязки к DataGrid нельзя удалять/пересоздавать список. Если вам нужно его перечитать целиком - выполняете Clear() и добавляете записи заново. Далее по таймеру считываете изменённые или добавленные записи и пробегаете по вашему списку и их находите и изменяете. Отрабатывает PropertyChanged на сообщениях, отрабатывает изменение списка, отрабатывает обновление DataGrid. Если у вас считывание из базы происходит недолго, то вам достаточно использовать DispatcherTimer. Он выполняется в том же потоке где живёт DataGrid и список сообщений. Если же вас это не устраивает и вы хотите поиграть в потоки, то вам нужно использовать потокобезопасные коллекции и/или устраивать синхронизацию действий. Но это тема другого вопроса.

По умолчанию, в консоли Windows кодировка 866.
Переключите кодировку перед выводом.

Console.OutputEncoding = System.Text.Encoding.UTF8;

Либо переключите консоль в режим UTF-8 в батнике:
chcp 65001

Для одновременной работы с файлом несколькими приложениями его нужно открывать во всех приложениях со специальным указанием: FileShare.ReadWrite

FileStream s2 = new FileStream(name, FileMode.Open, FileAccess.ReadWrite, FileShare.ReadWrite);

В этом случае все приложения смогут одновременно читать и писать в файл. Это накладывает определённые ограничения на приложения - они должны как-то договариваться и понимать куда они могут писать, а куда - нет.
Каждая программа должна писать только изменения в файл, а не переписывать его - иначе другие программы отвалятся.
Это большой геморрой. Так делать не надо.
Если вы всё-таки решитесь, то нужно файл разбить на блоки. Перед записью в блок программа будет его помечать, что-бы другие программы ждали, пока вы закончите с ним работать, после записи - сбрасывать пометку. Если данные удалились - нужна пометка, что блок удалён, так как нельзя сдвигать файл - его могут читать другие программы. Если данные увеличились в размере - ставить отметку удаления и записывать новые данные в конец. И тд, и тп.
Большая часть из этого заложено, например, в формат dbf. Но реализовывать всё это придётся руками.
Кроме того остаётся вопрос с синхронизацией изменений. Если вы в одной программе поменяли список - как об этом узнает программа на другом компьютере. Это может быть слежение за временем изменения файла, или за специальными отметками в файле ... Постоянные проблемы с синхронизацией, постоянное состояние гонки, взаимоблокировки и т.д. В общем, так делать не надо.
Конечно, если каждой запущенной программе отводится только одна строчка и другие её не трогают, то можно попробовать изменять только её.

Если у вас, в основном, чтения и иногда "точечные" изменения, то можно предложить следующий вариант:
при записи: ожидать завершение всех чтений, а затем блокировать файл с FileShare.None, изменить и отпустить.
при чтении: ожидать завершение записи, если она есть, затем открытие файла с FileShare.Read (это не блокирует другие чтения), быстрое чтение и закрытие файла.
Под ожиданием я понимаю попытку открытия файла с соответствующими параметрами, и в случае исключения повтор через таймаут.

Items используется для "поэлементной" работы, а ItemsSource для подключения коллекций. Нельзя работать с ними одновременно - либо Items, либо ItemsSource.
Поэтому ваш код должен преобразиться примерно в такой:

comboBox2.SelectedIndex = (comboBox2.ItemsSource as System.Data.DataView).IndexOf("Вася");

Но это не будет работать, так как в качестве элементов в ComboBox располагаются элементы из таблицы целиком, а не только имена. Поэтому лучше и удобнее пользоваться свойством SelectedItem, примерно так:

comboBox2.SelectedItem = (comboBox2.ItemsSource as System.Data.DataView).Find("Вася");

А ещё лучше через Binding связать свойство comboBox2.SelectedItem с каким-либо свойством вашей модели и использовать её.

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

При программировании на C# программирование C++ не нужно. Но часть примеров, особенно если сталкиваешься с чистым WinApi, или с COM (DCOM), или работой с необычными устройствами, написана на C++. Поэтому есть необходимость уметь читать и понимать примеры на C++. А иногда на VB или даже на Delphi.

Простой способ: Для формы разрешите AllowDrop и ловите событие DragDrop. В её параметрах будет описание того, что на вас кидают.

Сложный способ: для затравки прочитайте вот это https://habrahabr.ru/post/179131/.
Там описана реализация на Delphi, но последовательность действий такая же.
Нужно описать все функции, которые используются через DllImport. Вызвать DragAcceptFiles.
Переопределить Wndproc для формы protected override void WndProc(ref Message m), и там обрабатывать событие WM_DROPFILES и через DragQueryFile получить переданный список.

Мне кажется вопрос оптимизации подключения для приложения с одним полем и кнопкой добавить не самый актуальный, но:
Время создания и закрытия соединения с базой данных определяется вашими условиями. Если соединение с базой данных жизненно необходимо программе, и она сразу же грузит из неё данные и продолжает взаимодействовать всё время своего запуска, то в этом случае соединение создают и хранят до завершения программы.
Для некоторых программ, которые точечно взаимодействуют с базой данных, а также если между взаимодействиями возможно отключение БД или доступа к ней по сети, соединения создаются в момент обращения к БД и после работы соединение закрывают. Это как раз очень похоже на ваш случай. При этом можно учитывать, что в действительности физические соединения к базе данных не всегда сразу закрываются при закрытии DbConnection, а придерживаются на случай, если тут же понадобится его открыть.
С другой стороны, возможно сам факт ошибки соединения с БД уже сообщит пользователю о проблемах и ему не придётся узнавать это после заполнения многостраничной формы ввода. В этом случае желательно проверить соединение до ввода пользователя.

using System;

class Program
{
    [STAThread]
    static void Main(string[] args)
    {
        Console.WriteLine("Starting WpfApplication1.exe...");

        var domain = AppDomain.CreateDomain("WpfApplication1Domain");
        try
        {
            domain.ExecuteAssembly("WpfApplication1.exe");
        }
        catch(Exception ex)
        {
            Console.WriteLine(ex.ToString());
        }
        finally
        {
            AppDomain.Unload(domain);
        }

        Console.WriteLine("WpfApplication1.exe exited, exiting now.");
    }
}