я делал дебаг, оно просто отваливается на строке DeserializeObject.
Это значит, что вы не смогли завершить дебаг. Продолжайте его дальше. Я привел минимально рабочий код для такого же запроса как у вас - он работает. Так что ищите где именно ваша ошибка.
Можно, конечно, почему нет. Открываете подробное описание механизма работы очереди и сами реализуете в рамках вашей задачи - раз нет желания использовать готовые библиотеки.
Нет, просто как службу не получится. Интерфейс входы в систему запускается в отдельной графической сессии и для запуска графического приложения там надо по хитрому механизму через вин апи запускать.
Самый простой способ - эмуляция ввода пользователя. Вот тут рядом есть свежий пример работы с самим окном: там оно просто прячется. В вашем случае надо найти дочерние окна ввода пользователя и пароля, ввести в них текст и нажать кнопку/ввод для авторизации. Есть, конечно, еще такая штука как Credential Provider - но я в эту сторону не смотрел и деталей не знаю.
weranda Неее, какой еще на запрос? Это ВСЕ дерево. 17 гигов - это на все 4 миллиарда записей. Для 400к записей куда меньше надо памяти. Собственно я уже сделал замер и дополнил ответ. Полтора гига уже более реальное значение. Можно просто сделать стадартный апи, который просто будет просто читать/писать в дерево и его уже использовать под ваши нужды.
Нет, не крон. Последовательность реализуется проще всего именно через очередь. Поток/процесс берет задачу из очереди и выполняет её. Потоков может быть несколько - на сколько хватит мощности сервера столько и используете. Механизмов реализации очередей - куча. Самый простой - через редис.
Внесение изменений в продакшен БД означает, что у вас проблемы с организацией процесса разработки и его разворачивания, а не автоматизацией запросов в БД. В правильно организованном процессе разработки нет необходимости вносить изменения в продакшен БД напрямую.
Кстати, а проверяли на бумаге разной плотности и качества? Сдвиг - это очевидно проблема точного позиционирования головки ибо проблема пропадает при высоком качестве печати, в котором головка обычно движется медленнее. И т.к. на двух новых - то скорее всего это конструктивная особенность. Да, вероятность брака есть - так что в любом слуачае имеет смысл обратиться к производителю и спросить - чего это оно так печатает?
Ага, понятно. Наименования на русском и английском полностью раздельные? Тогда их можно ужать раздельной перекодировкой в 6 бит, например. Чем и как сжимаете индекс? Ссылку на код я закинул - если будете щупать/проверять - было бы интересно услышать результаты. На вскидку могу сказать, что при средней длине слова в 6-7 символов индекс на ArrayTree в 300 мегабайт может сожрать объем очень примерно в 70-100 гигов. А вот на более медленном ListTree уже компактнее: 5000000 х 7 / 329.8MB / 10.3GB. Вообще, можно и скомбинировать - например первые 4-7 символов в ArrayTree, а дальше уже ListTree, в конце которого ссылка на искомую строку. В 6 битной кодировке можно в 32 бита, т.е. 4 байта, уместить 5 символов. Так что комбинируя разные решения можно подобрать оптимальное соотношение скорости поиска и затрат памяти.
Это значит, что вы не смогли завершить дебаг. Продолжайте его дальше. Я привел минимально рабочий код для такого же запроса как у вас - он работает. Так что ищите где именно ваша ошибка.