IT Новости из мира ПК
10 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд

Postgresql ms access

Microsoft Access to PostgreSQL Conversion

From PostgreSQL wiki

by Jon Hutchings 20th July 2001



This page is intended as a quick user guide to converting an MS Access database for use with PostgreSQL. It is hoped that the reader has some experience of both Access and PostgreSQL, and this document is not intended to be a guide to the usage of those systems.

Stage 1 — on your Workstation running MS Access

The first stage in the conversion process is to download the PostgreSQL upsizing tool. This can be obtained from the authors website. I strongly recommend reading the authors documentation and also note the limitations listed below of this tool.

This tool takes the form of an MS Access 97 database.

Once opened, the main screen (frmmain) has a number of options relating to the SQL conversion.

Select the database that you want to convert., analyse it using the Analyse function and amend any parameters you need to change.

It is important to fill out the SQL database name field with the name you wish to give your final postgres database otherwise you will have more work to do later.

Check the Export data option to move the data across — amend the file locations in the Miscellaneous options section if necessary.

Use Create SQL to make the SQL files and then Export SQL. This will place all the files needed in stage 2 in the directory specified on the Miscellaneous tab of the amend Parameters screen within pgupt.

FTP these files to a suitable empty directory on your postgres server.

Stage 2 on your Linux Server running PostgreSQL

Log into your server and change to the directory where you have uploaded the files

If you did not give the database a name earlier then the following must be performed before proceeding

  • edit the file (for example joe will open the file in the joe editor).
  • Change all references to «test» in the file to the name which you want to give your database.
  • HINT — Don’t include non alphanumeric charaters in your database name (i.e. don’t use -_ ‘?/!»| etc.)
  • Save and close the file.
  • Open the create_schema.sql file and examine the table structure. Ensure that the fieldnames and data types are correct.

Issue the following command to make the executable

Execute the the script using the following command at your shell prompt.

This will execute the script and put the errors and output in a file called output1. If everything is working correctly the screen should display a CREATE for each table in the database, if you only see two create statements and you have three tables , then one of the tables has not been converted. In this case examine the log file (output1 in this case), for details. A common cause for this is the naming of tables or fields using SQL reserved words. For a list of these see the Postgresql documentation for your version of postgres.

WARNING: Once you have succesfully converted your database and it is in use you should NOT rerun this script as it will reinitialize your database back to the state in which it was when you converted it. I suggest that when your database is working you remove the execute permissions on the script to prevent accidential execution.

Stage 3 — Testing your database at the server console.

Once you are happy that the conversion has worked, you can test your database by connecting to it with the Postgresql monitor in the normal way. For example, if you called your database «customerdata» you would use

at a shell prompt on your linux postgres server to connect (you will probably need other command line options for usernames and passwords etc.). Once connected you should use the dt command to display a list of tables and compare it with the source database. If these look correct, try some simple queries such as

This will display (at some speed !) all the records, but more usefully at the end you will get a record count for that table which you can compare to ensure all the data has been converted correctly.

Stage 4 — ODBC Configuration

If you wish to continue to use Microsoft Access97 to interact with the converted database you will need to set up a suitable ODBC driver and datasource on the client PC(s).

The first stage is to download the PostgreSQL ODBC driver. This can be obtained via the PostgreSQL ODBC website.

Once installed, use the ODBC control panel on your Windows 9x/NT 4.0/Windows 2000 PC and add a new User DSN or user data source. Select the PostgreSQL driver and fill in the details with the server name, port, database name, username and password, for your postgresql server.

Stage 5 — MS Access Configuration.

To create an Microsoft Access based front end to the newly created PostgreSQL database, do the following:

Make a copy of your original Access database.

Open it in Microsoft Access.

Select the Tables tab.

Select Link Table.

In the Files of Type list select ODBC Databases.

In the data sources dialogue find the data source you created earlier (on NT 4.0 this will typically be on the Machine Data Sources tab).

Читать еще:  Point в c

Select the tables which you wish to link.

Once linked you are free to remove the old local tables and compact the database.

NOTE — If any field names have changed during conversion (usually due to the use of non-alphabetic characters in the field and table names) then your queries, forms and reports etc. will need updating to reflect this.


Firstly, I have only tested this script with Postgres 6.5.3 and Access 97, other combinations may work but are untested by me.

Secondly, ther are some limitations to this tool, which I have discovered, these are

  1. The tool expects at least one relationship, so simple single table database conversions will fail.
  2. The tool assumes you will be using the standard postgesql server port.
  3. Using this tool it is possible to generate trigger and function names longer than 32 characters which can cause postgresql some problems

Подключение таблиц PostgreSQL к базе данных MS Access

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

Основная проблема заключается в том, что для присоединения таблицы или представления с сервера требуется установить ODBC-драйвер и зарегистрировать в системе так называемое имя источника данных (Data Source Name, DSN), которое служит для хранения специфической информации о конкретном соединении, обеспечиваемом драйвером. Если приложению требуются соединения с различными серверами, базами данных или просто отличающиеся какими-либо параметрами, то потребуется создать несколько DSN.

Вручную сделать всё это очень просто. Достаточно запустить программу установки ODBC драйвера, а потом создать все нужные DSN с помощью Администратора источников данных ODBC, который находится в панели управления Windows. Проблема в том, что когда пользователей много, данная нехитрая процедура превращается в целое мероприятие. Как же автоматизировать этот процесс? Ну, с установкой драйвера всё достаточно просто: надо скопировать на компьютер пользователя необходимые файлы и добавить ключи в реестр Windows. Какие именно — зависит от самого драйвера. Это, конечно, может вызвать затруднения, однако, в крайнем случае, установить драйвер можно вручную один раз, а обновление версий проводить автоматически, как правило, заменой единственного файла динамической библиотеки.

Создать DSN ещё проще. В MS Access есть специальная функция для регистрации нового источника данных: Этим возможности Access и ограничиваются. Получить список источников данных и, тем более, значения отдельных параметров каждого источника с помощью встроенных средств MS Access невозможно. Однако не беда, процедуру RegisterDatabase можно запускать при каждом старте программы и, если Вы захотите установить другие значения параметров соединения, они просто будут перезаписаны поверх старых.

Дальше, надо собственно подключить внешние таблицы и представления к базе данных Вашего приложения. Тут есть два пути: первый — простой, но менее гибкий и, возможно, более интерактивный. Он предполагает использование команды DoCmd.TransferDatabase с типом преобразования acLink. Подробное описание приводится в справочной системе MS Access.

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

Теперь наша задача — создать объект TableDef таким образом, чтобы он оказался присоединённой таблицей, полностью пригодной для любых операций с данными. Сначала создадим сам объект TableDef: Как видите, нет необходимости специально указывать, что мы хотим создать именно присоединённую таблицу ODBC. Access сам определяет это анализируя строку подключения. О том, как её правильно сформировать — чуть позже. Теперь добавим только что созданное определение таблицы в коллекцию TableDefs: И в конце поможем Access’у определить первичный ключ, если он сам его не распознал, что является нормальным явлением при подключении представлений (VIEW): Самое сложное здесь — составить строку подключения. В начале обязательно нужно указать «ODBC;», затем — имя источника данных («ODBC;DSN= ;. «), имя пользователя («. ;UID= ;. «) и пароль («. ;PWD= ;. «) например: Далее, при необходимости, можно указать имя базы данных и другие параметры, в том числе, специфичные для используемого ODBC драйвера. Порядок следования опций не имеет особого значения, так как все они различаются по именам (DSN, UID, DB). В качестве разделителя используется точка с запятой (;). Например:

На этом можно было бы закончить, но нельзя не упомянуть, что у некоторых ODBC драйверов есть одна замечательная особенность: они позволяют подключать таблицы вообще без создания DSN. В их числе драйверы для MS SQL Server 7.0 и PostgreSQL. Для этого надо просто вместо параметра DSN указать параметр DRIVER и имя драйвера, заключенное в фигурные скобки. Конечно, в таком случае потребуется указать все необходимые драйверу опции. Например: Опций может быть довольно много и это вызывает очень серьёзную проблему: длина строки подключения не может превышать приблизительно 270 символов. Разработчики драйвера PostgreSQL это понимают и пытаются найти выход путём кодирования некоторых опций. Параметр CX и является таким кодом. Формируется он так: первые два байта содержат количество реально значимых битов в последующем числе (в шестнадцатиричном формате). Например, 18 означает, что используются 24 бита которые представляют следующие опции драйвера: Некоторые параметры невозможно закодировать таким образом и для их именования продолжают использовать буквоцифровые сокращения:

Читать еще:  Multipoint что это такое

Пример, который я сделал для Access’97, можно взять здесь. Он основан на подходе, описанном в заметке «Программное подключение таблиц из внешней базы данных MS Access», но содержит дополнительную таблицу, в которой хранится информация, необходимая для подключения к серверу. Так как сам подход достаточно универсален, пример годится для подключения не только к серверу PostgreSQL, но и к любому другому, возможно, с какими-нибудь незначительными доработками.

Строку подключения можно легко получить, присоединив таблицу вручную, а затем скопировав всё содержимое свойства «Описание» (кроме тега table=. ) из свойств таблицы, открытой в режиме конструктора. Для сервера PostgreSQL можно воспользоваться надстройкой, которую я создал специально для формирования строк коннекта и минимального администрирования сервера.

Access и PostgreSQL: подключение к БД, работа с таблицами

Доброго времени суток!

Возникла необходимость научиться работать через элементы управления, созданные в Access 2013 с PostgreSQL.

Для начала решил подключиться к БД и присоединить из нее тестовую пустую таблицу.

Что сделано:

  • Сервер PostgreSQL работает (на удаленном компе).
  • ODBC-драйвер на моем компе установлен.
  • PGAdmin с моего компа и сервер и базу и таблицу в ней видит.
  • Тест соединения из «Администратора источника данных ODBC» выдает положительный ответ.

Что не так:
При попытке подключиться (действие повешено на одну из кнопок) выдает ошибку 3151 «ODBC — ошибка подключения к PostgreSQL35W»

Код, который затыкается на последней строке (хотя дело явно не в ней):

PostgreSQL35W — название DSN в настройках источников данных ODBC
. ИМЯСЕРВЕРА. — на самом деле на это место ставилось имя сервера из PGAdmin’a или имя компьютера, на котором запущен PostgreSQL, что на результате не сказалось.
tt01 — таблица в базе данных pgtest.
From_PGSQL — наименование будущей подсоединенной таблицы в Access (если я все верно понял — оно может быть произвольным, в разумных пределах, пробовал дать имя соответствующее имени в PostgreSQL — tt01 — те же грабли).

Что я делаю не так?

Работа с таблицами Access на VBA
Уважаемые форумчане, владеющие VBA для Access! Помогите мне, пожалуйста, с решением следующей.

Работа с временными таблицами в VB6.0 + MS Access 20*
Добрый день, формучане. Во время реализации проекта по разработке базы данных склада на Visual.

Работа с таблицами и запросами Access на VBA
Уважаемые форумчане! Прошу посмотреть мою базу данных. В ней 3 простых таблицы и 1 модуль на.

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

Уважаемый mobile, благодарю за ответ!

Указанную статью видел, и делал все как раз так, как написано, после чего, в результате неудачи, и создал тему.

Пока разбирался дальше сам выяснил следующее. Одна из проблем состоит в разрядности ОС и Access. У меня х64 Win7 и 32-битный офис. Установленный драйвер ODBC был 64-битным и, по всей видимости, неверно воспринимался офисом. С ним и из Excel и «ручными» способом (через «Внешние данные» -> «база данных ODBC») в Access вылетала ошибка. После установки дополнительно 32-битной версии ручное подключение к БД и ее подключение в Excel заработало.

Теперь проблема в том, что после ручного подключения и отключения таблицы программный код срабатывает правильно (подключает ее), а без ручного подключения — нет. В результате «нет» вылетает ошибка 3000 («Зарезервированная ошибка (-7711); сообщение для данной ошибки отсутствует»).

Будем думать дальше.

Уважаемый alvk!
Цитирую продолжение своего предыдущего сообщения: «После установки дополнительно 32-битной версии ручное подключение к БД и ее подключение в Excel заработало.»
А вот проблема программного подключения посредством VBA никуда не делась.
Вручную таблица линкуется, после того, как приликнованную таблицу вручную же удалишь (так быстрее) — начинает работать и программная линковка.
Если прилинкованную таблицу удалить и перезапустить Access — снова не линкуется.
Если прилинкованную таблицу не удалять, перезапустить Access, удалить прилинкованную таблицу — снова не линкуется.
Если прилинкованную таблицу не удалять, перезапустить Access, открыть и закрыть прилинкованную таблицу, затем удалить прилинкованную таблицу — программный линк работает.

Понять что ручная линковка делает такого, что не получается сделать программно не получается.

Добавлено через 13 минут
Уважаемые коллеги, всем спасибо за помощь!

Оказалось проблема в двух моментах:
1) Версия ODBC драйвера — должна соответствовать битности Access (из-за этого была масса глюков)
2) Совершенно дурацкая ошибка с моей стороны — не учел регистр при наборе пароля После ручного подключения, видимо, где-то сохранялась информация о том, что правильный пароль был введен.

Проблема решена, тему можно закрывать.

Добавлено через 6 минут
Кому интересно — код:

Сервер PostgreSQL и MS Access

Сервер PostgreSQL пока мало распространён в нашей стране. Можно много гадать о причинах такого положения дел. Существенную роль тут, возможно, сыграла «доступность» большинства из хорошо известных коммерческих серверов фирм Oracle, Microsoft, Sybase и других.

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

И ещё, очень важно, на мой взляд, что долгое время отсутствовала возможность запустить сервер PostgreSQL под Windows. Теперь острота этой проблемы снята и можно без особого труда установить сервер PostgreSQL практически на любую версию Windows. Как это сделать достаточно подробно описано в заметке «Установка PostgreSQL под Windows’98».

Во многих других странах ситуация иная. PostgreSQL известен не менее, чем MySQL и во многих случаях замещает последний, если требуются возможности, которые тот пока обеспечить не в состоянии. Также он там часто применяется в различных бюджетных организациях (медицинских, образовательных и т.п.). О распространённости и высоком качестве PostgreSQL говорит и тот факт, что компания Red Hat выбрала его в качестве «придворного» сервера баз данных для своих дистрибутивов Linux. Следствием этого является присутствие PostgreSQL в отечественном дистрибутиве от ASP Linux.

Читать еще:  Справочники в access

Но наиболее важно другое — работа над сервером ведётся очень активно и из вспомогательного инструмента, обеспечивающего поддержку работы с базами данных для web-серверов, PostgreSQL в последнее время превращается в полноценный «движок», пригодный для использования в традиционных системах учёта, построенных по технологии клиет-сервер. А, как известно, клиентская часть таких систем часто создаётся с помощью MS Access.

Коротко о самом сервере

Я не хочу глубоко вдаваться в историю и лишь отмечу, что PostgreSQL уходит своими корнями в проект Postgres, который возглавлял профессор Калифорнийского Университета Микаэль Стоунбрейкер (Michael Stonebraker) и который субсидировался несколькими фондами и агенствами, преимущественно военными.

Основной платформой для PostgreSQL в настоящее время является Linux и другие UNIX-подобные операционные системы. Специальной версии для Windows не существует, хотя какие-то работы в этом направлении ведутся. Пока имеется возможность установить сервер PostgreSQL на практически всех версиях Windows с помощью эмулятора CygWin, в состав которого входит уже скомпилированный сервер PostgreSQL. Не считая проблем с поддержкой русской локали и несколько пониженного быстродействия, такой вариант вполне работоспособен.

Что касается средств администрирования, то это не самая сильная сторона PostgreSQL. Хотя необходимые программы конечно же имеются (архивация и восстановление, выполнение запросов, получение статистической информации и т.п.), все они имеют интерфейс командной строки. Единственное более-менее нормальное средство с графическим интерфейсом под Windows — pgAdmin II. Есть ещё что-то на PHP (с web-интерфейсом), но лично для меня такой вариант пока не очень удобен.

В отличие от многих других серверов, PostgreSQL поддерживает согласованность данных при многопользовательской работе используя не блокировки, а многоверсионную модель (MVCC — Multiversion Concurrency Control). Это означает, что каждая транзакция видит состояние данных таким, каким оно было на момент старта этой транзакции, независимо от текущего состояния данных. Таким образом, транзакция защищена от просмотра противоречивых данных, наличие которых может быть обусловлено действиями другой, параллельно выполняющейся транзакции. Если таблицу всё же необходимо заблокировать, то это можно сделать с помощью специальной команды LOCK.

Ссылочная целостность поддерживается вполне традиционным путём, с помощью определения ограничений (Constraints). Параметры ограничений достаточно разнообразны и охватывают все мыслимые случаи поведения при попытках нарушить целостность данных (каскадные удаления и обновления, работа с NULL и т.д.).

За свою долгую историю, PostgreSQL поднакопил приличное количество разнообразных типов данных, в том числе весьма экзотических (point, line, polygon, bit, macaddr и т.д.). Если и этого недостаточно, то можно создавать свои собственные типы и определять операции над ними. Также поддерживаются многомерные массивы переменной длины. При работе же с PostgreSQL через MS Access наиболее важны следующие типы данных:

Использование MS Access & ODBC для подключения к удаленному PostgreSQL

в настоящее время у меня есть приложение MS Access, которое подключается к базе данных PostgreSQL через ODBC. Это успешно выполняется в локальной сети с 20 пользователями (каждый из которых использует свою собственную версию Access). Теперь я думаю о некоторых сценариях аварийного восстановления, и кажется, что быстрый и простой способ защиты данных-использовать журнал доставка для создания теплого режима ожидания.

Это заставляет меня думать о том, чтобы поместить этот теплый режим ожидания в удаленное место, но тогда у меня есть вопрос:

доступен ли доступ к удаленной базе данных через ODBC? Т. е. удаленная база данных, возможно, находится в той же стране с ok ping times, и у меня есть линия SDSL 1mbit.

4 ответов

драйвер ODBC PostgreSQL -активно развивается и интерфейс доступа в сочетании с сервером PostgreSQL, на мой взгляд, делает отличный вариант в локальной сети для быстрого развития. Я был вовлечен в достаточно большую систему (100+ PostgreSQL таблицы, 200+ формы доступа, 1000+ запросы доступа и отчеты), и он отлично работает в течение нескольких лет, с

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

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

У меня нет опыта использования доступа к PostgreSQL из удаленного местоположения, но я успешно использовал доступ в качестве интерфейса к SQL Server & DB2 из удаленного местоположения с успехом.

по иронии судьбы, вы не хотите использовать доступ к интерфейсной базе данных Access (mdb) из удаленного местоположения по ссылке с высокой задержкой. Поскольку нажатие MDB использует файловые операции, довольно легко получить поврежденную базу данных, если у вас есть что-то большее, чем тривиальный db.

зависит много в базе данных, которую вы используете в качестве бэк-энда. У меня было довольно ужасные впечатления от MySQL в качестве бэк-энда. Убедитесь, что ссылка ODBC, которую вы используете, активно разработана, стабильна и завершена — это определенно не относится к MySQL. Вы также можете проверить наличие проблем совместимости между Access и Postgre. И, конечно, не помешает провести обширные испытания.

О, и я думаю, было бы совсем здорово, если бы вы может вернуться сюда позже с вашим опытом!

PostgreSQL отлично работает в качестве бэкэнда для MS Access, есть несколько функций поддержки, которые вы должны использовать, чтобы сделать вещи проще. См. здесь для получения дополнительной информации об этом:

Ссылка на основную публикацию