Как мне убедить кого-то, что ему нужно увеличить размер с MS доступа к серверу SQL или аналогичным

Question

У меня реальная проблема при работе с глубоко укоренившимся разработчиком, одержимым доступом к ms. Пользователи жалуются на случайные сбои, ошибки блокировки, зависания, замедление работы приложения (особенно в 2007 году), но, похоже, очень устойчивы к его перемещению. Большую часть времени они обвиняют компьютер и не могут быть уверены, что это тот факт, что это mdb, установленный на сетевом диске, и не имеющий ничего общего с оборудованием, установленным перед ними, что является совершенно новым.

Существует интерфейсная vb-программа, висящая на ней, но я не думаю, что на ее настройку уйдет больше пары недель, но я бы, вероятно, переписал ее, так как год за годом она имеет грязный код разработчик.

Каковы мои лучшие аргументы, чтобы убедить их, что мы должны переместить это?

У кого-нибудь еще есть подобные проблемы с разработчиками, застрявшими на их пути?

Answer 1

как насчет random, сбоев, ошибок блокировки, зависаний, замедлений (sic).

При быстром поиске в Интернете можно найти несколько полезных материалов:

• Рекомендации по использованию Microsoft Office Access 2003 в многопользовательской среде - если изменения здесь не могут быть реализованы или будут эффективно переписаны, то это хороший боеприпас для правильной работы .
• SQL Server и MS Access - обратите особое внимание на ограничения возможностей. Например, в БД доступа может быть только 32 000 объектов. Предостережение: хотя в нем говорится о 255 одновременных пользователях, и это, вероятно, техническое ограничение, практическое ограничение действительно НАМНОГО ниже.

Трудно убедить людей, которые не хотят учиться и не открыты для новых идей. Вы можете продолжить говорить о проблемах скорости, параллелизма, проблем безопасности ... но, в конечном счете, некоторые люди просто никогда не будут слушать. Пройдите через их головы. Перепишите его в инструментах этого десятилетия и покажите их. Отказаться от участия в проекте и дальше. Я не знаю, какова политическая ситуация, но технически доступ к MS не соответствует тому, что вы делаете, из того, что вы описали.

Answer 2

Забудьте аргументы о размере БД, это неосведомленная причина перехода на платформу клиент-сервер в 90% случаев, о которых я слышал.

Ваши лучшие аргументы основаны на функциях, объясненных на низком техническом уровне: (1) Вы можете создавать резервные копии и выполнять обслуживание БД, не выгоняя пользователей (что приводит к дорогостоящим простоям).

(2) Ускоренное восстановление, если данные были случайно удалены / искажены или повреждены. Опять же, меньше риска и меньше простоев. Это всегда хорошая основа для бизнес-кейса.

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

(4) Если вам нужно запускать автоматизированные задания / обновления, SQL может сделать это намного элегантнее.

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

Answer 3

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

Я создал надежные системы доступа на протяжении многих лет. Если у вас случаются случайные сбои, проблемы с блокировкой и замедления, значит, вы что-то делаете неправильно. У меня обычно будет локальный mda с mdb в сети при создании приложения в доступе. Чтобы иметь хорошую производительность, важно иметь правильные индексы и запросы, оптимизированные для получения именно тех данных, которые вам нужны. Независимо от того, используете ли вы отдельное приложение, доступ или какое-либо приложение, работающее на сервере SQL, вам нужно активно обрабатывать блокировку записей. Вы не можете просто слепо позволить доступу заблокировать ваши записи.

Answer 4

зайдите на выходных, скопируйте базу данных на сервер SQL, измените строки подключения приложения на сервер SQL, повторно протестируйте приложение, затем удалите ms-access ... везде.

затем не говорите ничего об этом , дайте ему подумать, что проблемы "исправились" и что пользователи все еще используют ms-access

Answer 5

Можно и на самом деле довольно легко преобразовать базу данных Access в таблицы / представления в SQL Server, в то же время используя приложение Access в качестве внешнего интерфейса.

Оттуда ваш одержимый Access разработчик может по-прежнему получать удовольствие от всего этого кода VBA. Между тем, на бэк-энде вы добавляете индексы и тому подобное для ускорения всего. Может быть, однажды вам повезет, и он спросит о хранимых процедурах. Тогда приложение - это просто интерфейс, и кого это волнует, что написано? Ваши данные в безопасности в SQL Server.

Вы можете сделать это самостоятельно, но просто оставьте производственное приложение ALOOOOOOOOOOOONE. Возьмите копию и конвертируйте эту копию. Затем поместите его на диск TEST для нескольких пользователей. Сделайте так, чтобы ваша версия приложения Access показала "TEST APP" большими красными буквами. Если ваш разработчик спрашивает, что вы делаете, вы можете сказать правду - вы тестируете, чтобы убедиться, что преобразование только таблиц / представлений может быть полезным для всего приложения.

Таким образом, вы получите лучшее из обоих миров, порадуете своего разработчика, сделаете пользователей счастливее (надеюсь), и если вы правильно сыграете, ваши начальники будут знать, что вы справились с запутанной кадровой проблемой с вашим технологическим мастерством и ваша зрелость.

Answer 6

Лучший совет, который я могу вам дать, - это убедиться, что у вас хорошее отношение и вас называют человеком, который делает качественную работу и добивается успеха. Похоже, у вас нет контроля над ситуацией, поэтому вам нужно влияние.

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

Будь хорошим человеком для работы, а не PITA, который знает, как все остальные должны писать свой код. Уметь дать ответ о том, что ты можешь сделать по-другому и почему, но не думай автоматически, что твои идеи всегда самые лучшие. Возможно, есть компромиссы, о которых вы не знаете - в бюджете нет денег на дополнительные клиентские лицензии, у нас есть другое приложение, которое нужно сделать в первую очередь. Это не похоже на вашу ситуацию, но поиск возможностей понять, прежде чем делать конструктивную критику, может иметь большое значение, помогая людям быть восприимчивыми.

Другое дело, что это, вероятно, не имеет никакого отношения к техническим аспектам ситуации и всему, что связано с ненадежностью другого разработчика. «Это все, что я знаю. Если мы изменим это, я не пойму это и тогда, где я буду». Ищите способы помочь другому человеку расти - когда у него возникают проблемы, найдите ресурсы, которые помогут ему разработать хорошие технические решения. Предложите всем сотрудникам вашего отдела пройти обучение новым технологиям. Кто знает, один хороший курс по SQL Server и парень может стать евангелистом по SQL Server в организации, потому что теперь ЭТО то, что он знает.

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

Answer 7

Это зависит от типа приложения и загрузки данных в вашей базе данных, но Access достаточно эффективен, даже по сети.
В зависимости от объема данных, с которыми имеют дело ваши пользователи, вы можете легко масштабировать до 100 пользователей в сети, просто используя базу данных доступа from и back-end.

Похоже, в вашем случае перезапись может быть в порядке. Если ваше приложение ориентировано на данные, если не имеет особого смысла разрабатывать его в VB6: инструменты, предоставляемые Access, намного лучше, чем все, что вы могли бы сделать, особенно при рассмотрении Access 2007.

Повышение до уровня SQL Server действительно требуется только в том случае, если возникают проблемы:

• Безопасность :
  Вы должны убедиться, что только пользователи с правами могут иметь доступ к данным. Вы можете обеспечить собственную безопасность в Access, но она никогда не будет столь же сильной, как SQL Server.
• Масштабируемость
  Вы имеете дело с большим количеством данных и сложными запросами или большим количеством пользователей, и было бы лучше иметь выделенное оборудование для обработки нагрузки для клиентов. Однако проблема заключается в том, что, снимая нагрузку с менее способных клиентов, вы добавляете на сервер гораздо больше.
• Целостность
  Поскольку внутренняя база данных является просто файлом, который требует доступа R / W для всех подключенных клиентов, всегда существует вероятность того, что кто-то собирается что-то сделать плохо или что клиент может произойти сбой и оставить базу данных поврежденной.

Если ваше число пользователей среднее (я бы сказал, 30), то, вероятно, нет необходимости увеличивать масштаб:

• Используйте MS Access 2007 для разработки своего приложения, а затем просто используйте MS Access 2007 Runtime (это бесплатно!) На всех клиентских машинах, чтобы получить более современный пользовательский интерфейс (использует ленту и имеет множество улучшений пользовательского интерфейса по сравнению с предыдущими версиями) .
  Вы не можете быть дешевым в этом решении: вам нужна только полная розничная версия MS Access, а все остальное бесплатно, не считая количества пользователей!
• Не думайте, что переход на SQL Server повысит производительность ваших запросов: MS Access часто лучше оптимизирует запросы для вас (он знает, что должно отображаться и выполняет много операций кэширования и оптимизации) .
• Убедитесь, что вы одновременно редактируете только небольшие объемы данных (не используйте запросы dynaset только для отображения огромных объемов данных в таблице данных; вместо этого используйте снимок и откройте детальную форму, содержащую только данные для редактирования) когда необходимо.
• Кэшировать сложные запросы локально.
  Встроен некоторый механизм кэширования, который оставляет копию результатов сложного запроса на локальном компьютере. Прирост производительности довольно впечатляющий, и если запрос не сильно меняется (например, журнал операций с запасами), вы можете просто сохранить сложный / большой запрос локально и добавлять новые записи по мере необходимости.

Можно сказать намного больше.

Суть в том, что вы, возможно, смотрите на переписывание, но не отклоняете Access как решение, потому что ваше текущее приложение было плохо написано.

Answer 8

Больше, чем «Как их убедить», давайте поговорим о «Как это сделать, чтобы никто не заметил»!

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

Если ваш код действительно невыносим, ​​перед тем как перейти на SQL, перепишите приложение, помните о следующих моментах, чтобы сделать окончательный переход на SQL Server полностью прозрачным для конечных пользователей.

Это то, что мы сделали 18 месяцев назад, и я уверен, что у нас все еще есть пользователи, считающие нашу базу данных Access:

1. Экспорт текущей базы данных доступа в SQL с помощью доступного мастера в доступе для целей тестирования (может возникнуть много проблем, и вам может понадобиться другой инструмент, такой как предложенный здесь ).
2. Создайте уникальный объект соединения на уровне приложения, чтобы вы могли свободно переключаться с Access на SQL в любое время (на уровне разработки вы даже можете добавить поле ввода при запуске, чтобы спросить, какое соединение использовать). Мы выбрали объект подключения ADODB, но он также будет работать с подключением ODBC.
3. Если вы используете синтаксис SQL для обновления таблиц, убедитесь, что все SELECT, INSERT, UPDATE и DELETE используют это соединение. Если вы используете набор записей, убедитесь, что все они используют это соединение во время открытия.
4. При необходимости обновите весь код, связанный с подключением, добавив «SELECT CASE» type_Of_TheConnexion options
5. Переключитесь на соединение SQL ... и отлаживайте, пока не закончите!

Проблемы, которые вы обнаружите, в основном связаны с синтаксисом SQL, где MSSQL использует «вместо» и # в качестве разделителей. Формат даты также является проблемой, где стандартный формат SQL - «ГГГГММДД», а формат MS-Access зависит от компьютера. locals (остерегайтесь преобразований из даты в строку!) и хранится как «ГГГГ-ММ-ДД» (если я помню ...). Булевы значения в SQL равны 0 и 1, в то время как они равны True / False или 0 / -1 в доступе ...

Протестируйте, обновите код и, когда все в порядке, сделайте новую передачу данных, заблокируйте ваше приложение на соединении SQL и распространите новую среду выполнения.

Answer 9

Если они сопротивляются, вы всегда можете пойти выше их головы. Руководство должно знать о сбоях и проблемах, связанных со стабильностью. Представьте им план по улучшению стабильности, и они, вероятно, хотя бы прислушаются. Тогда они, вероятно, захотят встретиться со всеми разработчиками, чтобы обсудить их, поэтому вооружитесь боеприпасами.

Answer 10

Однажды у меня были похожие проблемы с кем-то, кого я бы не стал называть полным идиотом.

Не удалось убедить их в проблемах с доступом. В конце концов, было легче навязать проблему, чем сделать это «красиво», жестоко быть добрым.