Продление эксплуатации и миграция приложений VB6 / Access — таблица решений: оставить, обернуть или заменить

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

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

Чтобы читать эту статью, достаточно двух предпосылок. Первая: и VB6, и Access — это в основном 32-битные технологии на базе COM (ActiveX / OCX), и стык с сегодняшними 64-битными Windows и Office легко становится проблемой. Вторая: как рамку решения мы берём тройку «оставить / обернуть / заменить». Подробности по COM, VBA и прочим отдельным технологиям даны ссылками по ходу текста, а если хотите собрать предпосылки одним блоком, все они перечислены в «Похожих статьях» в конце. При первом чтении можно идти сплошняком и не открывать ссылки из текста.

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, тоже есть привязка к разрядности 32/64 бит. На одной машине ставится только одна разрядность, и она должна совпадать с разрядностью Office.² Начиная с Office 2019 / Microsoft 365 по умолчанию ставится 64-битная версия, поэтому приложения Access и элементы ActiveX, собранные под старое допущение о 32 битах, могут перестать работать в момент замены компьютера.³⁴
• Одновременное открытие общего .accdb из сетевой папки несколькими людьми до сих пор часто встречается на местах, но остаётся фактором риска повреждения данных и падения производительности. Документация предупреждает, что запись по сети при нестабильном соединении может повредить данные.⁵ Когда растёт объём учёта или число одновременных пользователей, пора рассматривать перенос на SQL Server и аналоги.
• Ось решения та же, что для ActiveX / OCX: это просто экран или граница, за которой живут бизнес-логика и данные. Стабильно работает и область замкнута — оставляем; нужно модернизировать только часть — оборачиваем; ограничения UI или платформы тормозят бизнес — заменяем. Дальше думаем в этом порядке.
• «Обернуть» в этой статье значит: сам старый актив не трогают, а вокруг него готовят новую точку входа (внепроцессный COM-сервер, связанные таблицы SQL Server, веб-API и т. п.), чтобы снаружи с ним можно было работать как с новым механизмом. Содержимое не переписывают, поэтому трудозатраты проще оценить. Это временная площадка, чтобы сначала модернизировать только самые рискованные места (глава 8).

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 22, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

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

Сначала зафиксируем факты. 8 апреля 2008 года Microsoft заявила, что «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 и как это проверить».

Кто от чьей разрядности зависит, легко перепутать, поэтому зависимости сведены в таблицу (основания по каждой строке — те же источники, что в этом разделе и в главе 2).

Вертикаль таблицы — это и есть путь, по которому авария расползается. Сменилась разрядность Office (первая строка) — вместе с ней ударят ACE, компоненты, которые загружает Access, и свои приложения, которые к ним подключаются. Первый пункт, который стоит проверить перед обновлением компьютеров, всегда один: «какой разрядности Office на новой машине».

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-запросы или представления.⁸ Кроме того, давно рекомендуется разделять приложение Access на «бэкенд»-базу с таблицами и «фронтенд»-базу с формами, запросами и макросами.⁹ Важно другое: одного разделения недостаточно. Правильная схема — в общей папке держать только бэкенд (таблицы), а фронтенд копировать на компьютер каждого пользователя и работать из локальной копии. Если фронтенд тоже остаётся одним файлом в общей папке, который все продолжают открывать вместе, то даже после разделения остаётся риск одновременного чтения и записи форм, запросов и макросов в общий файл. Отсюда дольше открывается база и конфликты при смене дизайна. Продлеваете ли вы схему с общей папкой или уходите на SQL Server, первая контрольная точка одна: сделаны ли обе вещи — общий бэкенд и фронтенд на каждом компьютере.

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

flowchart TB
    subgraph CLIENTS["Компьютер каждого пользователя — своя копия"]
        FE1["Фронтенд .accdb<br/>формы, запросы, отчёты, VBA"]
        FE2["Фронтенд .accdb<br/>та же копия у другого пользователя"]
    end
    BE["Бэкенд .accdb в общей папке<br/>только таблицы"]
    SQL[("SQL Server / Azure SQL<br/>сюда переносят при росте нагрузки")]
    FE1 -->|"связанные таблицы"| BE
    FE2 -->|"связанные таблицы"| BE
    BE -.->|"перенос (upsizing)"| SQL
    FE1 -.->|"связи после переноса"| SQL
    FE2 -.->|"связи после переноса"| SQL

Рис. 1: Разделение бэкенда и фронтенда и последующий перенос на 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-битного приложения
• Основы блокировок при файловом обмене — блокировка файла и атомарный claim

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

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, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.