Comments 16
Проще, кажется, использовать, например, DBeaver и Import MS Access DB into MySQL DB
Совместимых форматов у этих СУБД нету (как оказалось)
Обе СУБД прекрасно общаются с CSV - Access по щелчку пальцев экспортирует:
SQLite точно так же без проблем импортирует (эта часть, слава богу, описана).
Кстати, ничто не мешает прямо из Access подключиться к SQLite по ODBC (соответствующий пункт на скриншоте - имеется) и вообще перегнать данные напрямую, в принципе избегая промежуточного хранилища.
И теперь мы можем произвести все необходимые манипуляции с таблицей, например перевести её другой язык и т.п.
Эхх.. и передача данных - через третьи руки, и их редактирование - опять через третьи руки..
Больше всего похоже, что автор взялся за то, чем вообще никогда не занимался, но вместо серьёзного исследования и изучения сляпал абы как, лишь бы получилось.. а потом, вместо того, чтобы сдать работу и помалкивать о том, через какое место она делалась, ещё и выволок всё своё незнание на всеобщее обозрение. И даже гордится им..
Вы бы, друг мой, не позорились, а?
Я на всякий случай оставлю это здесь (сорри, я автор) -
https://ksdbmerge.tools/cross-dbms-diff-merge-overview.html
Открываем в одной панельке файл аксес, в другом - файл с SQLite базой
В бесплатной версии нужно будет пройтись по очереди по табличкам, для каждой нажать "выделить все записи" и "мерж". В платной можно это сделать сразу для всех таблиц.
Из минусов, по крайней мере по сравнению с подходом из статьи - таблички в SQLite базе должны быть созданы заранее, с таким же набором колонок и первичным ключом (есть планы на будущее по импорту схемы, но пока сильно далекие).
Еще наверно стоит отметить что в аксесе есть multivalue типы данных которые вряд ли могут быть нормально перелиты предложенными способами.
в аксесе есть multivalue типы данных которые вряд ли могут быть нормально перелиты предложенными способами
Хорошо бы понять, о чём именно Вы ведёте речь... в любом случае всё нормально перельётся (правда, не в случае, когда приёмником выступает SQLite - уж больно бедненько там с типами), дав на выходе либо ENUM, либо SET. В последнем случае можно также воспользоваться JSON-массивом.
Можно также подумать об автоматическом создании таблицы-словаря и внешнего ключа в неё.
Ну и универсальный вариант - использование на приёмнике TEXT/BLOB поля,- может быть использован вообще практически в любом случае.
Я веду речь о https://support.microsoft.com/en-us/office/create-or-delete-a-multivalued-field-7c2fd644-3771-48e4-b6dc-6de9bebbec31. В значении поля такого типа будет лежать список, к мультивелью относятся в том числе и аттачмент поля.
>> Можно также подумать об автоматическом создании таблицы-словаря и внешнего ключа в неё.
Чтобы сохранить структуру, тут на каждое такое поле нужно создавать отдельную таблицу с отношением многие-к-одному на основной набор данных. В каких-то случаях и дополнительная таблица-словарь может быть полезна. В общем, потребует какого-то кастомного решения.
Ааа... ну это типичнейший SET. Сами данные - это маска битовых флагов, а в метаданных таблицы хранятся текстовые описания этих флагов. Очень хорошо такой тип данных, включая и начинку под капотом, описан, например, в Reference Manual у MySQL.
Просто M$ не может же использовать стандартные именования, несолидно, им надо непременно что-то своё оригинальное выдумать... мир, правда, не прогибается, но надежда умирает последней.
Чтобы сохранить структуру, тут на каждое такое поле нужно создавать отдельную таблицу с отношением многие-к-одному на основной набор данных
Ну в принципе это куда как более правильное решение, чем использование SET. Костыль - он и есть костыль. Где-то упрощает, где-то усложняет. Но в простейших случаях как раз ему самое место.
Я знаком с SET в MySQL, на первый взгляд да, может быть похоже, но в общем случае - нет. Набор значений может задаваться внешней таблицей или запросом (аналог внешнего ключа). Даже если это фиксированный список как в SET - можно удалить значение из списка в "схеме" и при этом оставить уже выбранные значения в данных. В случае аттачментов это вообще произвольный список пар блоб плюс имя файла.
Не уверен что плод больной фантазии MS, это вполне могло быть содрано из какого-нибудь файлмейкера - еще один популярный на западе инструмент для создания баз данных вместе с интерфейсом, наподобие аксесса.
Набор значений может задаваться внешней таблицей или запросом (аналог внешнего ключа).
В любом из этих случаев мы имеем скрытую статическую таблицу либо запрос, причём работает оно на уровне интерфейса, а не на уровне самой БД. А само поле остаётся текстовым (или что там выбрано) - если изменить список, то ранее введённые значения, даже в новой версии списка отсутствующие, никакого отторжения у БД не вызывают. И флаг "ограничиться только значениями из списка" для уже существующих данных не помогает, хотя злостно нарушает целостность. То есть подсистема контроля непротиворечивости данных просто спит.
Сложность была так же в том, что моя подопытная БД была с Окном
что бы это значило?
Кажется я созрел для написания статей на Хабр.
Если уж такое тут можно, то мне есть чего припомнить!
прямо вот так открывать и пересохранять экселем данные для миграции - такое себе, он может поменять их как ему вздумается, а что именно он поправил не напишет. Даже если вам сделали и прислали эксельку, нужно убедиться, что локаль в системе у вас и у создателя файла совпадает. Как указано выше, лучше использовать csv, и если и трогать их экселем, то импортировать через Data->Import Text File, аккуратно расставив типы данных в колонках.
Вспомнилось как во времена ковида англицкий минздрав потерял часть данных при экспорте через Excel. Не учел лимиты на количество столбцов. В вашем случае вы можете так же потерять строки сверх лимита Excel. А еще можно неслабо так споткнуться если при импорте из csv неправильно определится тип столбца, или данные не будут соответствовать полям таблицы. Так что, быстро? — да, надежно? — нет.
Как экспортировать БД из Access в SQLite: короткий гайд