Продление жизни и миграция бизнес-приложений VB6 / Access ── таблица решений «оставить, обернуть или заменить»

«Часть основной системы всё ещё написана на VB6», «журнал, сделанный в Access, на самом деле держит на себе работу целого отдела» - на консультациях для малого и среднего бизнеса эти две ситуации до сих пор встречаются на удивление часто. Общее в них то, что человек, который всё это создал, обычно уже уволился, и никто не может точно объяснить, почему это вообще работает. Тем не менее, оно продолжает работать без сбоев, поэтому приоритет на его обновление неизбежно откладывается.

В этом блоге мы уже разбирали отдельные технические темы: что такое COM / ActiveX / OCX, таблицу решений «оставить, обернуть, заменить» для ActiveX / OCX и ограничения и перспективы VBA. Эта статья сужает фокус до двух крупнейших легаси-активов, до сих пор широко распространённых в японском малом и среднем бизнесе, - приложений на VB6 и бизнес-приложений на Microsoft Access, - и собирает практическое руководство по тому, оставлять ли их как есть, продлевать ли жизнь, обернув только часть, или заменять целиком. Схема решения повторяет ту же тройку «оставить / обернуть / заменить», что использовалась в статье про ActiveX / OCX, но поскольку объект другой, содержание рисков тоже другое, поэтому здесь мы сосредоточимся на вопросах, специфичных именно для VB6 и Access.

1. Сначала вывод

• Официальная поддержка IDE и среды разработки самого VB6 закончилась в апреле 2008 года. Официального способа вести новую разработку или доработку больше не существует.¹
• При этом рантайм VB6 (msvbvm60.dll и сопутствующие файлы) работает, пока поддерживается версия Windows, с которой он поставляется. Утверждение «существующее приложение на VB6 в целом продолжает работать на поддерживаемой Windows» до сих пор верно, но оно полностью подчинено сроку поддержки самой Windows.¹
• VB6 - технология только для 32 бит, нативной 64-битной компиляции не существует. На 64-битной ОС он работает внутри WOW64, среды совместимости с 32-битными приложениями.¹ В момент, когда возникает необходимость взаимодействовать с 64-битными DLL, SDK или COM-компонентами, задача перестаёт умещаться в один процесс.
• У «Access Database Engine» (ACE), читающего и записывающего файлы .mdb / .accdb Access, тоже есть привязка к разрядности 32/64 бита. На одной машине может быть установлена только одна разрядность, и она должна совпадать с разрядностью Office.² Начиная с Office 2019 / Microsoft 365 по умолчанию устанавливается 64-битная версия, поэтому приложения Access и элементы ActiveX, созданные под старое допущение о 32 битах, могут в один момент перестать работать при замене компьютера.³⁴
• Одновременное открытие общего файла .accdb из сетевой папки несколькими людьми до сих пор часто встречается на практике, но остаётся фактором риска повреждения данных и снижения производительности. Указано, что запись по сети при нестабильном соединении может привести к повреждению данных.⁵ Когда объём журнала или число одновременных пользователей растёт, наступает момент задуматься об апгрейде до SQL Server и подобных решений.
• Критерий решения тот же, что и для ActiveX / OCX: является ли актив просто экраном или границей, несущей в себе бизнес-логику и данные. Если он стабильно работает и его область замкнута - оставляем; если нужно модернизировать лишь часть - оборачиваем; если ограничения UI или платформы тормозят бизнес - заменяем.

2. Текущее состояние VB6 ── рантайм жив, но опоры со стороны разработки больше нет

Сначала уточним факты. Microsoft заявила 8 апреля 2008 года, что «IDE Visual Basic 6.0 (и IDE Visual Studio 6.0) больше не поддерживается», ясно обозначив позицию: официального способа создавать и сопровождать приложения на VB6 больше не существует, и настоятельно рекомендуется переход на современные технологии.¹

При этом в том же заявлении говорится, что рантайм VB6 остаётся объектом поддержки, пока поддерживается версия Windows, с которой он поставляется. Ожидается, что существующие приложения на VB6 будут «просто работать» на поддерживаемой Windows, а объём поддержки ограничен устранением серьёзных регрессий и критических проблем безопасности.¹ То есть минимальное ожидание «не должно сломаться при установке на новую Windows» оправдано, но поддержки в смысле «добавят функциональность или разберутся с конкретной проблемой по запросу» - нет.

Ещё один момент, важный на практике: рантайм VB6 - это файл только для 32 бит, и на 64-битной ОС он поддерживается лишь внутри среды 32-битной эмуляции WOW64.¹ Это означает, что «приложение на VB6 и дальше сможет жить только как 32-битный процесс». Когда возникает желание использовать 64-битный SDK измерительного прибора или новую криптографическую библиотеку, загрузить их напрямую в процесс VB6 принципиально невозможно. Единственный практический способ преодолеть эту стену - «вынести функциональность в отдельный процесс и связать их», и конкретную конфигурацию из статьи «Пример COM-моста, вызывающего 64-битную DLL из 32-битного приложения» можно применить как есть. При использовании моста из приложения VB6 подход тот же: 64-битная функциональность заключается в внепроцессный COM-сервер или вспомогательный EXE, а сторона VB6 лишь вызывает его.

Многие приложения на VB6 несут в себе элементы ActiveX / OCX в качестве компонентов экрана. Решение «оставить, обернуть или заменить» для самих этих компонентов подробно разобрано в статье «Как сегодня обращаться с ActiveX / OCX», за решением по отдельным элементам управления, встроенным в приложение VB6, обращайтесь туда. В этой статье мы сосредоточимся на решении более высокого уровня - как поступить с приложением VB6 целиком.

3. Текущее состояние Access ── формат файла, разрядность ACE и реальность общих папок

3.1 .mdb / .accdb и разрядность ACE

Данные Access хранятся в файлах .mdb (старый формат) или .accdb (начиная с 2007 года), а рантайм-компонент, читающий и записывающий их, - это Access Database Engine (ACE, преемник Jet). На практике постоянно возникает проблема несовпадения разрядности. Прежний провайдер Jet OLE DB поставляется только в 32-битной версии, а ACE доступен и в 32-битной, и в 64-битной версиях, однако на одной машине можно установить только одну из них, и она должна совпадать с разрядностью Office на этой машине.² Со стороны Visual Studio тоже описаны случаи: поскольку Visual Studio 2022 и новее работают как 64-битный процесс, инструменты данных, использующие 32-битный провайдер Access, перестают подключаться.⁶

Ситуацию дополнительно усложняет изменение значения по умолчанию на стороне Office. Office 2010-2016 по умолчанию устанавливал 32-битную версию, но начиная с Office 2019 и Microsoft 365 по умолчанию устанавливается 64-битная версия.³ Кроме того, 64-битный процесс Office не может загружать 32-битные бинарники, поэтому существующие 32-битные элементы ActiveX и COM-надстройки просто не работают в 64-битном Office.⁴ Иными словами, за многими случаями «годами пользовались одним и тем же приложением Access, а после замены компьютера оно вдруг перестало работать» стоит переключение разрядности Office по умолчанию, за которым не успели ACE и встроенные элементы управления. Порядок диагностики подобных проблем изложен в статье «Причины и порядок проверки, почему ActiveX не работает в Office 2024/Microsoft 365».

3.2 Риск многопользовательской работы через общую папку

Ещё одна классическая конфигурация приложений Access - одновременное открытие файла .accdb, лежащего в общей папке, несколькими людьми. При небольшом масштабе это годами работает без проблем, но по сути такая схема опасна. Указано, что запись по сети при нестабильном соединении может привести к сбою записи или повреждению файла,⁵ а случаи, когда Access сообщает о дисковой или сетевой ошибке при задержке или таймауте доступа к файловому серверу, известны давно.⁷ Сам зародыш повреждения - одновременный доступ к общему файлу - по структуре очень похож на конкурентные паттерны, разобранные в статье этого блога «Основы взаимоисключающего доступа при интеграции файлов». В Access встроен механизм взаимоисключающего доступа через файл блокировки (.laccdb), но чем больше «маршрутов, склонных к нестабильности соединения» - ноутбуков через Wi-Fi, удалённой работы через VPN, переподключений после выхода из режима сна, - тем выше частота сбоев.

Стандартный путь отступления при росте числа одновременных пользователей или усложнении обработки - перенести таблицы Access на SQL Server или Azure SQL, а со стороны Access обращаться к ним как к связанным таблицам. С помощью инструментов вроде SQL Server Migration Assistant (SSMA) таблицы Access мигрируются, после чего исходные таблицы Access заменяются ссылками на таблицы в новом месте - экраны (формы, отчёты, запросы) остаются как есть, на более надёжное хранилище переносятся только данные.⁸ Однако перевод на связанные таблицы несёт свои специфичные проблемы после миграции: агрегирующая обработка может замедлиться (если запрос зависит от функций, которые не может выполнить сервер, Access целиком стягивает таблицу локально и лишь затем обрабатывает её), меняется поведение колонок автонумерации, - в некоторых случаях требуется переход на прямые запросы (pass-through queries) или представления.⁸ Также издавна рекомендуется разделять приложение Access на «бэкенд»-базу данных с таблицами и «фронтенд»-базу данных с экранами, запросами и макросами.⁹ Важно здесь то, что одного разделения недостаточно. Правильная конфигурация - держать в общей папке только бэкенд (таблицы), а фронтенд копировать на компьютер каждого пользователя и работать с него из локальной копии. Если фронтенд тоже остаётся единым файлом в общей папке, который все продолжают открывать вместе, то даже при разделении сохраняется риск «одновременного чтения и записи экранов, запросов и макросов в общий файл», что приводит к таким проблемам, как ухудшение времени ожидания при открытии и конфликты при изменении дизайна. Продлеваете ли вы жизнь схемы с общей папкой или переходите на SQL Server, первая контрольная точка - проверить, реализованы ли обе вещи: «общий доступ к бэкенду» и «размещение фронтенда на каждом отдельном компьютере».

4. Таблица решений

Если систематизировать приложения VB6 и Access по ситуации использования и факторам риска, получается следующая таблица решений.

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

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

5. Применение решения по сценариям

При наложении таблицы решений на реальные консультации она чаще всего сходится примерно к трём паттернам.

Сценарий 1: внутреннее приложение управления складом на VB6, запросы на изменения невелики. Если целевые компьютеры зафиксированы в количестве нескольких штук и не выходят в сеть, таблица решений склоняется к «оставить». Практическая работа здесь сводится к последовательному накоплению мер снижения риска из главы 7 (резервное копирование, документирование, фиксация среды выполнения). Пока нет реальной мотивации переходить на .NET, экономика чаще всего не сходится.

Сценарий 2: журнал Access, общий для нескольких отделов, число пользователей растёт. Частая консультация: несколько лет назад приложением Access пользовались 2-3 человека, но из-за объединения отделов или расширения бизнеса число одновременных пользователей выросло примерно до десяти. В этом случае таблица решений склоняется к «обернуть». Сначала проверяем, реализованы ли общий доступ к бэкенду и локальное размещение фронтенда на каждом компьютере (раздел 3.2); если нет - сначала разделяем и переразмещаем. После этого, если проявляются признаки повреждения или снижения производительности (увеличилось время ожидания при открытии, остаются файлы .laccdb с неснимаемой блокировкой и т. п.), переходим на перенос таблиц в SQL Server и обращение к ним со стороны Access как к связанным таблицам.⁸ Поскольку экраны можно оставить почти без изменений, удаётся укрепить хранилище данных, сдерживая затраты на переобучение пользователей.

Сценарий 3: основное приложение на VB6, разработчик которого уволился, есть запрос на переход в веб. В ситуации, когда исходники есть, но никто не может их трогать, и появился запрос на использование извне компании, таблица решений склоняется к «заменить». Однако чем более центральную роль играет приложение, тем выше риск полной единовременной переписки. По порядку из главы 9 - сначала инвентаризация бизнес-логики и выделение функций с малым влиянием и высокой независимостью - и продвижение через поэтапную миграцию является более реалистичным путём.

6. Частые антипаттерны

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

Из этого списка особенно часто встречаются два: оставленное без внимания смешение разрядностей и бесконтрольный рост числа пользователей общей папки. Оба объединяет то, что это не проблемы «сломается сегодня» - они проявляются в момент какого-нибудь неизбежного триггера, вроде обновления компьютеров или роста числа пользователей.

7. Реалистичные меры снижения риска при решении оставить

Решение оставить всё как есть часто реалистично, и само по себе это не ошибка. Однако чем дольше продолжается принцип «работает, поэтому не трогаем», тем больше накапливается риск того, что никто не сможет объяснить исходные допущения. Как минимум стоит позаботиться о следующем:

• Механически вести версионное резервное копирование. Поскольку .accdb в Access целиком помещается в один файл, уже одно лишь ежедневное версионное резервное копирование способно поглотить значительную часть сбоев. Для приложений VB6 сохраняем полный комплект исходников (.vbp, .frm, .bas, .cls) вместе с зависимыми OCX, DLL и сведениями о регистрации в реестре.
• Документировать допущения о среде выполнения на случай отсутствия преемника. Фиксируем поддерживаемую ОС, разрядность Office, необходимые рантаймы, зависимые DLL и процедуру регистрации, как минимум с той детализацией, чтобы было понятно, «что проверять, если перестало работать на новом ПК».
• Намеренно фиксировать среду выполнения. Поскольку автоматическое обновление Windows или Office, меняющее разрядность или настройки по умолчанию, становится триггером сбоя (раздел 3.1), для целевых компьютеров стоит выделить отдельную политику обновлений и разворачивать обновления только после предварительной проверки.
• Подготовить smoke-тест на чистом окружении. Перед развёртыванием на новом компьютере полезно иметь процедуру, подтверждающую, что установка, регистрация, запуск и основные операции проходят на девственно чистой машине - это сокращает время, теряемое каждый раз на ситуацию «должно работать, но не работает».
• Свести точки вызова в одно место. Вместо того чтобы разбрасывать COM-вызовы VB6 или ссылки на связанные таблицы Access по всему приложению, стоит по возможности сузить точки входа - это делает понятной отправную точку для будущего оборачивания или замены.

Как специфичный для VB6 момент, стоит упомянуть и сохранение самой машины разработки. Установочные носители и лицензия IDE, версии для разработчиков внешних элементов управления (OCX), необходимых для сборки, и заметки о процедуре сборки - это активы, которые теряются даже легче, чем сама среда выполнения. Даже если в ближайшее время доработки не планируются, сохранение одной среды (например, снимка виртуальной машины), в которой сборка воспроизводима, сильно расширяет варианты действий в момент, когда небольшая доработка всё же понадобится.

Если нужно поддерживать и дорабатывать существующее ПО для Windows, не ломая его, это относится к области модернизации и сопровождения существующего ПО для Windows.

8. Реалистичные варианты при решении обернуть

«Обернуть» - это подход, при котором старый актив заключается внутри узкой границы, а окружению предъявляется новый интерфейс. Для VB6 и Access это в основном сводится к следующим трём паттернам.

(a) Вызывать COM-компонент VB6 из .NET через COM interop. Если класс, написанный на VB6, опубликован как ActiveX DLL (или EXE, если он внепроцессный), его можно вызывать со стороны .NET через COM interop. Поскольку сторона VB6 остаётся 32-битной, при вызове из 64-битного приложения .NET встаёт та же стена разрядности, что упоминалась в главе 2. Выбор между тем, выровнять ли вызывающую сторону на 32 бита или заключить компонент в 32-битный процесс как внепроцессный COM-сервер, можно вывести, просто перевернув конфигурацию из статьи «Пример COM-моста, вызывающего 64-битную DLL из 32-битного приложения». Об основах самого COM - в статье «Что такое COM / ActiveX / OCX».

(b) Поэтапно переносить логику VBA в Access на .NET / веб. Среди приложений Access встречаются как случаи, где за формами скрывается плотная бизнес-логика, так и случаи, ограничивающиеся простым вводом и просмотром данных. Реалистичный путь - сначала провести инвентаризацию модулей VBA, выделить чисто вычислительную и проверочную логику, не зависящую от других систем, в библиотеку классов .NET, и постепенно переводить обращение к ней со стороны Access на COM или промежуточный веб-API. Ограничения самой VBA и критерий того, что стоит оставить в VBA, подробно разобраны в статье «Что такое VBA - ограничения, перспективы и случаи, когда стоит заменить».

(c) Сначала заменить только UI, сохранив данные и логику. Если недовольство сосредоточено вокруг того, что формы Access устарели, работают медленно или недоступны извне компании, есть вариант оставить слой данных (таблицы, перенесённые в SQL Server) и логику как есть, заменив современными веб- или настольными технологиями только UI. В сочетании с переводом на связанные таблицы из раздела 3.2 возможен переходный режим двойной работы: «данные в SQL Server, а старый UI (Access) и новый UI смотрят на одни и те же данные». Однако если VBA на стороне Access тесно связывает UI и логику, само это разделение невозможно провести без предварительной инвентаризации по пункту (b).

Сведём три варианта в таблицу:

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

9. Как действовать при решении заменить

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

1. Сначала провести проверку миграции данных. В миграциях вроде Access → SQL Server встречаются различия, которые проявляются только после переноса: разница во времени присвоения автонумерации, зависимость от функций, существующих только в Access, отсутствующие уникальные индексы и т. п.⁸ Прежде чем переходить к переключению на продакшн, стоит завершить взаимную проверку миграции и бизнес-сценариев на копии реальных данных.
2. Провести инвентаризацию бизнес-логики. Разобрать формы/модули VB6 и VBA/макросы/запросы Access по функциям и определить, «просто ли это экран» или «граница, несущая в себе спецификацию». Способ разграничения тот же, что и для ActiveX / OCX, но в случае VB6 и Access специфическая сложность в том, что само накопленное за годы эксплуатации понимание бизнеса и есть актив, поэтому его обнаружение обычно занимает больше времени.
3. Продвигаться через поэтапную миграцию (паттерн Strangler). Вместо замены всей функциональности разом сначала выносим в новую систему функции с низким риском и высокой независимостью и на определённый период запускаем старое и новое приложения параллельно. Минимальное условие, чтобы этот подход не развалился, - чётко определить по каждой функции, какие данные (старые или новые) считаются достоверными, и заранее задать условия завершения периода параллельной работы.
4. Заранее завершив замену UI-компонентов или компоновки экранов, дальнейшую работу облегчить проще. Если приложение VB6 использует ActiveX / OCX как компоненты UI, замена только этих компонентов на современные элементы управления заранее облегчает оценку последующей полной замены. Отдельные решения - в статье «Как сегодня обращаться с ActiveX / OCX».
5. Подготовить средства наблюдения на период параллельной работы. Пока старое и новое приложения работают параллельно, нужно подготовить логи или механизм сверки, позволяющий сравнивать, какая обработка дала какой результат. Если продвигать переключение без средств наблюдения, есть риск заметить сбой в духе «после перехода на новую систему цифры перестали сходиться» лишь спустя месяцы.

Услугой, охватывающей всё - от инвентаризации спецификаций старых приложений Windows до поэтапной замены, - является замена приложений Windows.

10. Чек-лист для начала миграции

Если перед применением таблицы решений (глава 4) провести инвентаризацию в следующем порядке, время на принятие решения по направлению заметно сократится.

1. Составить перечень объектов. Свести файлы .exe / .dll / .ocx VB6 и .mdb / .accdb Access в список по имени файла, версии и месту размещения.
2. Проверить ситуацию использования. Уточнить число пользователей, наличие одновременного доступа, работу ли это через общую папку, а также частоту использования - ежедневную или ежемесячную.
3. Проверить допущения о среде выполнения. Выяснить поддерживаемую версию Windows, разрядность Office, наличие необходимых рантаймов, зависимых DLL и регистраций COM (главы 2-3).
4. Проверить местонахождение и объём данных. Для Access - узнать размер файла, число таблиц, число записей и темп роста. Это материал для решения о необходимости перехода на SQL Server.
5. Оценить сложность бизнес-логики. По числу строк модулей VBA, числу макросов, числу форм, числу форм и модулей классов со стороны VB6 прикинуть примерный объём трудозатрат на инвентаризацию.
6. Проверить наличие резервного копирования и процедуры восстановления. Для объектов, у которых резервные копии не ведутся или восстановление ни разу не пробовалось, это нужно наладить в первую очередь, ещё до самого решения.
7. Применить полученные результаты к таблице решений. Как только объекты и ситуация использования упорядочены, сверяем их с таблицей из главы 4 и предварительно, по функциям, решаем, к чему они склоняются - оставить, обернуть или заменить.

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

11. Итог

При принятии решения по VB6 и Access первым делом стоит смотреть не на «насколько это старо», а на следующие три пункта:

• Правильно ли понимается, что VB6 - это среда выполнения только для 32 бит, потерявшая опору со стороны IDE (глава 2)?
• Учтено ли, что ACE и ActiveX в Access привязаны к разрядности Office, а работа через общую папку тем рискованнее в плане повреждений, чем больше одновременного доступа (глава 3)?
• Удаётся ли определить, является ли данный актив просто экраном или границей, несущей в себе бизнес-логику и данные (таблица решений из главы 4)?

Как только эти три пункта прояснены, дальнейшие шаги складываются естественным образом: при решении «оставить» - зафиксировать среду выполнения и не пренебрегать резервным копированием и документированием (глава 7); при «обернуть» - защитить данные и логику через 32/64-битный мост или поэтапный переход на .NET/веб (глава 8); при «заменить» - сначала провести проверку миграции данных и инвентаризацию бизнес-логики (глава 9). VB6 и Access - это не объекты, которые нужно бездумно выбрасывать только потому, что они старые, а материальное воплощение многолетних бизнес-знаний. Однако от домашнего задания в виде фиксации среды выполнения, проработки границ и проверки миграции, необходимого для дальнейшего сосуществования с этими активами, бесконечно уклоняться не получится. Рекомендуем начать с инвентаризации по чек-листу из главы 10.

Похожие статьи

• Что такое VBA - ограничения, перспективы и реалистичные паттерны миграции
• Как сегодня обращаться с ActiveX / OCX - таблица решений «оставить, обернуть, заменить»
• Что такое COM / ActiveX / OCX - разбираем различия и связь
• Причины и порядок проверки, почему ActiveX не работает в Office 2024/Microsoft 365
• Пример COM-моста, вызывающего 64-битную DLL из 32-битного приложения
• Основы взаимоисключающего доступа при интеграции файлов - лучшие практики блокировки файлов и атомарного захвата

Смежные направления консультаций

Komura Software LLC занимается инвентаризацией существующих активов, включая VB6 и Access, и проработкой направления миграции, проектированием продления жизни, включая 32/64-битные мосты, а также планированием и реализацией поэтапной замены.

• Поддержка использования существующих активов и миграции
• Замена приложений Windows
• Модернизация и сопровождение существующего ПО для Windows
• Техническая консультация и ревью архитектуры
• Контакты

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Работают ли приложения на VB6 в современной Windows?

Официальная поддержка IDE (среды разработки) VB6 закончилась в апреле 2008 года, но рантайм VB6 (msvbvm60.dll и сопутствующие файлы) остаётся поддерживаемым, пока поддерживается версия Windows, с которой он поставляется. То есть существующие приложения на VB6 в целом продолжают работать на поддерживаемой Windows. Однако VB6 - технология только для 32 бит, и на 64-битной ОС она работает внутри среды совместимости WOW64, поэтому в момент, когда требуется взаимодействие с 64-битными DLL, SDK или COM-компонентами, приходится выносить эту логику в отдельный процесс и связывать их между собой.

Почему после замены компьютера перестало работать приложение на Access?

В большинстве случаев причина - изменение разрядности Office. Office 2010-2016 по умолчанию устанавливался в 32-битной версии, но начиная с Office 2019 и Microsoft 365 по умолчанию устанавливается 64-битная версия. ACE (Access Database Engine), читающий и записывающий данные Access, можно установить на одном компьютере только в одной разрядности - 32 или 64 бита, и она должна совпадать с разрядностью Office. Кроме того, 64-битный Office не может загружать 32-битные элементы ActiveX и COM-надстройки, поэтому компоненты, изначально созданные под 32 бита, перестают работать на новом компьютере.

Есть ли проблема в том, что несколько человек одновременно открывают файл Access из общей папки?

Это фактор риска повреждения данных и снижения производительности. Запись по сети при нестабильном соединении может приводить к повреждению данных, и чем больше в работе ноутбуков через Wi-Fi или домашних подключений через VPN, тем выше частота сбоев. Как минимум стоит перейти на разделённую конфигурацию: в общей папке держать только бэкенд с таблицами, а фронтенд с экранами и запросами скопировать на компьютер каждого пользователя. Когда число одновременных пользователей растёт, наступает момент задуматься о переходе на таблицы в SQL Server, к которым Access будет обращаться как к связанным таблицам.

Что выбрать для приложения на VB6/Access - оставить, обернуть или заменить?

Ключевой критерий - является ли актив просто экраном или границей, которая несёт в себе ещё и бизнес-логику с данными. Если компьютер и версия Windows зафиксированы, а запросы на изменения невелики, экономически оправдано оставить приложение как есть, обеспечив резервное копирование, документирование и фиксацию среды выполнения. Если нужна 64-битная интеграция или укрепление хранилища данных, часть функциональности можно обернуть через COM-мост или перевод таблиц на связанные таблицы SQL Server. Если разработчика больше нет и сопровождение зашло в тупик, либо есть запрос на веб-версию, - это повод для замены, но реалистичнее не бросаться сразу в полную переписку, а сначала провести проверку миграции данных и инвентаризацию бизнес-логики, продвигаясь поэтапно.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.