Пошарился по интернету, по форуму. Попробовал свести всё в одно место.

Access. Переход с 32-х разрядной системы на 64-х разрядную.

Начиная с версии Office 2010, офис стал выпускаться в двух вариантах 32-х разрядный и 64-х разрядный. Причём, если 32-х разрядный офис может спокойно устанавливаться как на 32-х, так и на 64-х разрядную системы, то 64-х разрядный офис может ставиться только на 64-х разрядную операционку.

Хотя 32-разрядные приложения могут работать прозрачно, смешивание двух типов кода в одном процессе не поддерживается. 64-разрядное приложение не может подключаться к 32-разрядной системной библиотеке (DLL); аналогичным образом 32-разрядное приложение не может подключаться к 64-разрядной системной библиотеке.

ВНИМАНИЕ! При попытке запустить 32-разрядный код в 64-разрядной версии Access возникнут ошибки времени выполнения. Например, из-за несоответствия версий пользовательского приложения (32-разрядный код) и одного из 64-разрядных поставщиков ACE, установленных с 64-разрядной версией Microsoft Access, может возникнуть ошибка "Поставщик Microsoft.ACE.OLEDB.12.0 не зарегистрирован на локальном компьютере". Чтобы устранить эту проблему, либо обновите пользовательский код до 64-разрядной версии, либо удалите 64-разрядную версию Access и установите 32-разрядную.

Параллельная установка 64-х и 32-х разрядных выпусков Office 2010 не поддерживается. Это относится и к Access.

Перед развертыванием 64-разрядной версии Access определите, подходит ли такой вариант развертывания для конкретной среды. На совместимость с текущим 32-разрядным решением для Access влияет ряд факторов. Например, при использовании баз данных с удаленным исходным кодом (MDE-, ADE- и ACCDE-файлов) либо при использовании VBA-кода с операторами Declare, надстройками COM и элементами ActiveX необходимо приложить определенные усилия, чтобы эти функции заработали с 64-разрядной версией Access. Для устранения этой проблемы также можно установить 32-разрядную версию Access в 32-разрядной версии Windows либо 32-разрядную версию Access (WOW64) в 64-разрядной версии Windows.

Если Вы собираетесь использовать 64-х разрядные базы данных Access, и в будущем ситуация не изменится, самым естественным вариантом для работы с данными будет выбор драйвера ACE DAO, поскольку он предоставляет наиболее полный набор функций. В конце концов, собственные технологии доступа к данным, как правило, позволяют сократить время разработки, упростить код и обеспечить более высокую производительность. Если будут использоваться расширенные возможности работы с наборами данных и подключения к вспомогательным внешним источникам, рассмотрите возможность использования ADO.NET (или ADO) либо OLE DB. Полную поддержку устаревших возможностей, таких как связанные таблицы и сохраненные запросы, а также новых сложных типов данных, появившихся в Access 2007, обеспечивает только драйвер ACE DAO. Драйвер ACE OLE DB обеспечивает ограниченную поддержку сложных данных. Например, для более эффективной поддержки сложного набора данных (для извлечения наборов записей в наборах данных) необходимо задать параметр подключения "JET OLE DB: Support Complex Data". Если этого не сделать, по умолчанию для сложных полей будут возвращаться списки разделенных значений. Технологии ADO.NET, ADO и ACE ODBC всегда возвращают для сложных полей списки разделенных значений.

Выполнение кода VBA, который был написан до выпуска Office 2010 (VBA версии 6 и более ранних версий), на 64-разрядной платформе может приводить к возникновению ошибок, если код не был модифицирован для работы в 64-разрядных версиях Office. Ошибки будут возникать по той причине, что язык VBA версии 6 и более ранних версий неявно ориентирован на 32-разрядные платформы и обычно содержит операторы объявления, которые запускают в действие функции API Microsoft Windows, использующие 32-разрядные типы данных для указателей и дескрипторов. Так как язык VBA версии 6 и более ранних версий не имеет специального типа данных для указателей и дескрипторов, им используется тип данных Long, который является 32-разрядным 4-байтным типом данных, предназначенным для ссылки на указатели и дескрипторы. Указатели и дескрипторы в 64-разрядных средах являются 8-байтными 64-разрядными числами. Эти 64-разрядные числа не могут храниться в 32-разрядных типах данных.

Проблема с выполнением унаследованного программного кода VBA в 64-разрядном пакете Office заключается в том, что при попытке загрузить 64-разрядные значения в 32-разрядный тип данных 64-разрядные числа усекаются. Это может приводить к переполнениям памяти, неожиданным результатам в коде и возможным сбоям приложения.

Для устранения этой проблемы и обеспечения правильной работы кода VBA как в 32-разрядных, так и в 64-разрядных средах в язык VBA добавлен ряд функциональных возможностей. Три важных добавления: псевдоним типа LongPtr , тип данных LongLong и ключевое слово PtrSafe .

LongPtr — теперь язык VBA включает псевдоним типа переменной: LongPtr . Фактический тип данных, в который разрешается тип LongPtr , зависит от версии пакета Office, в котором он используется: тип LongPtr разрешается в тип Long в 32-разрядных пакетах Office, и тип LongPtr разрешается в тип LongLong в 64-разрядных версиях пакета Office. Используйте тип LongPtr для указателей и дескрипторов.

LongLong — тип данных LongLong — это 64-разрядные целые числа со знаком, которые доступны только в 64-разрядных версиях пакета Office. Используйте тип LongLong для 64-разрядных целых чисел. Для явного присвоения значений типа LongLong (включая тип LongPtr на 64-разрядных платформах) целочисленным типам данных меньшего размера должны использоваться функции преобразования. Неявное преобразование типа LongLong в целочисленные данные меньшего размера не допускается.

PtrSafe — ключевое слово PtrSafe декларирует, что оператор Declare безотказно выполняется в 64-разрядных версиях пакета Office.

Теперь все операторы Declare должны содержать ключевое слово PtrSafe , когда выполняются в 64-разрядных версиях пакета Office. Важно понимать, что просто добавление ключевого слова PtrSafe в оператор Declare означает только, что оператор Declare явно ориентирован на 64-разрядные данные, все типы данных в операторе, которые предназначены для хранения 64 разрядов (включая возвращаемые значения и параметры), все еще нуждаются в изменении, чтобы хранить 64-разрядные числа.

Начиная с Access 2010 для программирования стал доступен VBA7.

Операторы Declare , содержащие слово PtrSafe , работают корректно в среде разработки VBA7 как на 32-разрядных, так и на 64 разрядных платформах. Чтобы обеспечить обратную совместимость в VBA7 и более ранних версиях, используйте следующую структуру:



Примечание. Я писал текст программ в Access 2003, а уже потом отлаживал в Access 2010. В Access 2003 строки с этой переменной подсвечивались красным, но компилятор Access 2003 их спокойно обрабатывал. В Access 2010 ничего не подсвечивалось.

Пример не модифицированного унаследованного оператора Declare в языке VBA5/6 версий Access 97/2000/2002/2003/2007



Пример оператора Declare языка VBA модифицированного для включения спецификатора PtrSafe , но по-прежнему используется 32-разрядное возвращаемое значение в языке VBA7 версий Access 2007/2010/2013/2016



Пример оператора Declare языка VBA, модифицированный для включения ключевого слова PtrSafe и обновленный для использования 64-разрядного типа данных ( LongPtr )



Итак, для правильной работы кода в 64-разрядных версиях пакета Office необходимо найти и модифицировать все существующие операторы Declare , чтобы они использовали спецификатор PtrSafe . А внутри этих операторов Declare необходимо найти и модифицировать все типы данных, которые ссылаются на дескрипторы или указатели, чтобы использовать псевдоним нового 64-разрядного совместимого типа LongPtr и типы, необходимые для хранения 64-разрядных целых чисел с новым типом данных LongLong . Кроме того, следует обновить все определенные пользователем типы, содержащие указатели или дескрипторы и 64-разрядные целые числа, чтобы использовать 64-разрядные типы данных, и убедиться в правильности присвоений всех переменных, чтобы предотвратить появление ошибок несоответствия типов.

Чтобы написать код, переносимый между 32-разрядными и 64-разрядными версиями Office, требуется лишь использовать для всех указателей и значений дескрипторов псевдоним нового типа LongPtr вместо типа Long или LongLong . Псевдоним типа LongPtr разрешается в правильный тип данных Long или LongLong в зависимости от того, какая версия пакета Office используется.
Обратите внимание, что если требуется реализовать другую логику, можно использовать константу условной компиляции Win64

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



Чтобы написать код, работоспособный как в новой, так и в старой версиях Office, можно использовать комбинацию новых условных констант компилятора VBA7 и Win64.




************************************************************
Замечания, предложения есть?

-------------------------------------------------------------
А ты вложил уже свой кровный рубль в 50-ти миллиардное состояние Билла Гейтса?

Аргументы? Пожалуйста. Есть заказчик. Есть начальства. Достаточно?

Пост не о целесообразности перехода на 64-х разрядную версию, а о том, как это делать.

Пояснение.
Если тебя приглашает возможный(!) заказчик и говорит, что у них стоит Windows 8.1 (64) и Office 13 (64) И могу ли я разработать под эту конфигурацию небольшую базу по прохождению служебных записок? Вопрос предполагает только два ответа ДА или НЕТ. Их не интересует что Вы скажите о том, что 32-х разрядная версия лучше, надёжнее или им хватит и её возможностей. Люди сделали выбор (или скорее всего его сделали за них) и менять систему или офис по Вашим требованиям они не будут. Тем более за всё уплачено. Им проще найти другого исполнителя.

Продолжение.
Из опыта перехода.
Переводил на 64-х битную версию небольшую программу написанную в Access 2000. Без ActivX и API. Что замечено.
Что замечено.
Если у Вас есть ссылка на библиотеку Microsoft DAO 3.6 Object Library , то замените её на Microsoft Office XX.X Access Database Engine Object Library


Что насчет ядра Microsoft JET?До выпуска Access 2007 в Access использовалось ядро Microsoft Joint Engine Technology (JET). Хотя ядро JET обычно рассматривается как компонент Access, оно является отдельным продуктом. С момента выпуска Microsoft Windows 2000 ядро JET было включено в состав операционной системы Windows, после чего распространялось и обновлялось в составе компонентов Microsoft Data Access Components (MDAC). После выпуска Access 2007 ядро JET было признано устаревшим и было исключено из состава MDAC. Вместо этого ядра в Access теперь используется интегрированное и усовершенствованное ядро ACE, разработка которого началась с создания снимка исходного кода JET.

Ядро ACE полностью обратно совместимо с предыдущими версиями JET, что позволяет выполнять чтение и запись данных в MDB-файлы из предыдущих версий Access. Поскольку ядро теперь отдано группе разработчиков Access, другие разработчики могут быть уверены в том, что их решения для Access не только продолжат работать в будущем, но станут быстрее, надежнее и получат поддержку новых возможностей. Например, с выпуском Access 2010 в ядре ACE, в числе прочих усовершенствований, была реализована поддержка 64-разрядной версии и улучшена интеграция с технологиями и веб-службами SharePoint. Корпорация Microsoft обязуется поддерживать Access в качестве платформы разработки.


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

cylindrJoss,

Я вот тоже перехожу сейчас, мне очень помог ваш совет с dao 3.6 Спасибо Огромное! Пожалуйста.
Вот может пригодится. В приложенном файле Win32API_PtrSafe.txt даны декларации API функций для 64-х битной версии. Но не для всех API!. Остальные придётся декларировать самостоятельно. Деятели от MS считают, что пользователи с этим справятся.