...надо бы пояснить парочку терминов.
Да, надо бы кое-что пояснить. Тем более, когда ошибся. Вот так умничаешь, а потом краснеть приходится. Не атавизм, в данном случае, а рудимент, если еще точнее и совсем по-умному, то вестигий. Устаревшая хрень, пережиток, не до конца отвалившийся хвост. Это я про Microsoft Access, на котором построена база данных K3. Никаких его сказочных преимуществ не вижу. Но об этом ниже.
Я решил использовать pypyodbc, потому что pyodbc не умеет создавать БД, а только читает. Вроде так, уже не помню.
Действительно, проиндексировал исходники pyodbc, посмотрел, не умеет. Но только для Access не умеет, для SQL Server
не проблема. Думаю, что дело в самом Access. Смотрю, как pypyodbc создает базу mdb, вижу обходной маневр и только под Windows.
- Код: Выделить всё
def win_create_mdb(mdb_path, sort_order="General\0\0"):
if sys.platform not in ('win32', 'cli'):
raise Exception('This function is available for use in Windows only.')
# .......................................................................................................
# CREATE_DB=<path name> <sort order>
ctypes.windll.ODBCCP32.SQLConfigDataSource.argtypes #............
pyodbc мог бы что-то похожее предложить, но почему-то не предлагает. Есть вроде подобный
вариант создать mdb файл, вот только зачем? Одно дело, когда жизнь, под видом Геоса и K3, заставляет пользоваться Access, а самому-то зачем? Это я так к альтернативам перехожу.
Абстрактно рассуждая (кто нас будет спрашивать), хотел бы видеть вместо Access другую СУБД. SQLite, например (сейчас придет Алек(андр и будет ругаться). Для нужд прайс-листа и всяких таблиц сверловки за глаза хватит. Тот же принцип, одна база — один файл.
Работает везде и на всем. Ничего качать и ставить не надо, никаких скачек с драйверами и бубном, доступна "из коробки" K3. Куча полноценных утилит во free вариантах (навскидку,
1,
2,
3). С ног до головы
покрыта тестами, цитата с хабра:
покрытие кода тестами 100% (с августа 2009)
— причем это не просто покрытие тестами, а 100% branch coverage и 100 MC/DC покрытие, и вообще цифры покрытия тут совсем не главные, их можно было гораздо меньшими усилиями достичь, чем в sqlite это сделано.
Ни в каком другом open-source проекте такой помешанности на тестах не встречал. В sqlite кода тестов в 1000+ раз больше, чем собственно кода проекта, даже с учетом того, что многие тесты написаны на более высокоуровневом Tcl. Всем рекомендую почитать
http://www.sqlite.org/testing.html — душераздирающее чтиво
MySQL или PostgreSQL, понятно, круче, особенно вторая, но как по мне, так это даже не из пушки по воробьям, это ковровая ядерная бомбардировка по муравьям. Тем более, что их нужно ставить, администрировать, совсем другие ресурсы потребуются. А поставочная база K3 на Access для тех клиентов, кого не смущает ведение прайс-листа на конструкторском компьютере и использование "народных" версий Microsoft Office.
Хотя прайс-лист вообще желательно из общей базы изъять ("советы постороннего", да), придумать некий обобщенный интерфейс, через который уже цеплять отдельную базу с прайс-листом, пусть даже на Access в качестве примера. Кому Access нафиг не сдался, мог бы через этот интерфейс что-то свое подвязывать. Я в свое время начинал двигаться в сторону 1С, но не успел. Да и тяжело это на "шестерке" было делать и одному, особенно, когда все это совершенно непонятно руководителю с очень средним образованием.
pyodbc 311 для python 35 будет работать с python 33?
А зачем это выяснять? Есть же
pyodbc 3.07. Только опять потребуется установленный в систему Python.
Как то так!