Я перешел из Access в MySQL (InnoDB)
фронтенд - это доступ, а бэкэнд - это MySQL. InnoDb используется вместо MyISAM для использования функций отношений.
В моем исходном приложении Access у меня были рабочие отношения 1: 1. Вы можете увидеть это здесь
Для миграции я использовал "Bullzip" для данных и это для отношений. (Ответ Ивана Качикатари)
Поскольку этот код только что дал мне отношения 1: N, мне пришлось вручную редактировать модель схемы.
Модель выглядит так: 
После того, как я сделал модель в точности похожей на мои исходные отношения доступа, я синхронизировал ее со своей схемой.
Описание таблиц:
У меня есть таблица StockChange (Bestandsaenderung). Первичный ключ BestandsanederungID
Когда что-то меняется в Return (Rückgabe), Postions (Positionen) или Incoming goods (Wareneingang), оно также регистрируется в StockChange, и первичный ключ StockExcahnge автоматически вставляется в таблицы (X-BestandsaenderungIdREF)
Код на MYSQL (я просто сосредотачиваюсь на этих двух таблицах. Когда одна таблица имеет работающую 1: 1 реализацию, другие, надеюсь, легко)
CREATE TABLE `tbl_lager_bestandsaenderungen`
(
`BestandsaenderungID` int(11) NOT NULL AUTO_INCREMENT,
`BestandsaenderungArtikelIDRef` int(11) DEFAULT '0',
`BestandsaenderungAnzahl` int(11) DEFAULT '0',
`BestandsaenderungDatum` datetime DEFAULT NULL,
`BestandsaenderungVorzeichen` int(11) DEFAULT '1',
`BestandsaenderungInventur` tinyint(1) DEFAULT '0',
PRIMARY KEY (`BestandsaenderungID`),
KEY `BestandsaenderungArtikelIDRef` (`BestandsaenderungArtikelIDRef`),
KEY `BestandsaenderungID` (`BestandsaenderungID`),
CONSTRAINT `tbl_Lager_Artikeltbl_Lager_Bestandsaenderungen` FOREIGN KEY (`BestandsaenderungArtikelIDRef`) REFERENCES `tbl_lager_artikel` (`ArtikelID`) )
CREATE TABLE `tbl_lager_wareneingang` (
`WareneingangID` int(11) NOT NULL AUTO_INCREMENT,
`WareneingangLieferantIDRef` int(11) DEFAULT '0',
`Einkaufspreis` decimal(19,4) DEFAULT '0.0000',
`WareneingangBestandsaenderungIDRef` int(11) DEFAULT '0',
PRIMARY KEY (`WareneingangID`),
UNIQUE KEY `WareneingangBestandsaenderungIDRef_UNIQUE` (`WareneingangBestandsaenderungIDRef`),
KEY `WareneingangLieferantIDRef` (`WareneingangLieferantIDRef`),
KEY `WareneingangID` (`WareneingangID`),
KEY `fk_tbl_lager_wareneingang_tbl_lager_bestandsaenderungen1_idx`(`WareneingangBestandsaenderungIDRef`),
CONSTRAINT `fk_tbl_lager_wareneingang_tbl_lager_bestandsaenderungen1` FOREIGN KEY (`WareneingangBestandsaenderungIDRef`) REFERENCES `tbl_lager_bestandsaenderungen` (`BestandsaenderungID`),
CONSTRAINT `tbl_Lager_Firmentbl_Lager_Wareneingang` FOREIGN KEY (`WareneingangLieferantIDRef`) REFERENCES `tbl_lager_firmen` (`LieferantID`)
)
Для проверки, все ли в порядке, я снова создал модель с помощью «Обратного инжиниринга», чтобы посмотреть, существуют ли еще реалии 1: 1, но опять это соотношение 1: N.
Моя проблема в том, что в моей форме доступа PrimaryKey изменения запаса не вставляется в таблицу входящих товаров ForeignKey WareneingangBestandsaenderungIDRef.
Для лучшего объяснения я сделал видео .
В чистом доступе все работало идеально. Сразу после миграции все отношения 1: 1 больше не работают.
EDIT:
Когда я ввожу данные в подчиненную форму (Wareneingang), PK MainForm (Bestandsaenderung) вставляется в WareneingangBestandsaenderungIDREf. 
Кроме того, если я пытаюсь зафиксировать эту вторую дочернюю запись, я получаю
"ODBC - сбой вызова. Дублирующая запись '1' для ключа
'WareneingangBestandsaenderungIDRef_UNIQUE' (# 1062) "
... так что это показывает, что движок MySQL обеспечивает соотношение 1: 1.
Но в моей форме он все равно не вводится автоматически , как вы можете видеть в моем видео .