получаю странное исключение от CDBException:
Database error: Data source name not found and no default driver specified.
х86 версия работает нормально. исходный проект
Пользовал этот драйвер, как он показывается в ODBC DSN (х64) диалоге:
CString sDriver = "MICROSOFT ACCESS DRIVER (*.mdb,*.accdb)";
Windows 10, x64, Access 2016
Что не хватает?
gok>получаю странное исключение от CDBException: gok>Database error: Data source name not found and no default driver specified. gok>х86 версия работает нормально. gok>исходный проект gok>Пользовал этот драйвер, как он показывается в ODBC DSN (х64) диалоге: gok>CString sDriver = "MICROSOFT ACCESS DRIVER (*.mdb,*.accdb)"; gok>Windows 10, x64, Access 2016 gok>Что не хватает?
Не хватает — правильного решения для работы с БД.
Так как MFC совсем не дружит с БД, то самое верное: применять ту библиотеку, которая всё это реализует без MFC.
Мы обычно применяем OTLv4 для всех наших MFC проектов:
Библиотека очень удобная и легкая, в отличие от монстроидальных классов MFC для работы с БД.
Представлена библиотеке — в виде одного заголовочного файла, компилируется — под какую угодно БД (но, естественно для Windows).
Работать с ODBC для MS SQL Server с этой библиотекой — легко и приятно.
Если что нужно — спрашивайте здесь (скину примеры)!
Здесь очень простая connection string (не надо возиться с MFC-строкой соединения):
пример строки:
sa/12345@ODBCDSNName
где:
"sa" — это логин (стандартный для MS SQL Server)
"12345" — это пароль
"ODBCDSNName" — имя ODBC источника данных.
P.S. Вообше-то правильнее было бы именно работать через ODBC-DSN источник данных, а не пытаться уйти от него.
Если у Вас несколько БД, то создайте несколько ODBC-DSN источников (по каждому для соответствуюшей базы).
gok>>получаю странное исключение от CDBException: gok>>Database error: Data source name not found and no default driver specified. gok>>х86 версия работает нормально. gok>>исходный проект gok>>Пользовал этот драйвер, как он показывается в ODBC DSN (х64) диалоге: gok>>CString sDriver = "MICROSOFT ACCESS DRIVER (*.mdb,*.accdb)"; gok>>Windows 10, x64, Access 2016 gok>>Что не хватает?
AG>Не хватает — правильного решения для работы с БД. AG>Так как MFC совсем не дружит с БД, то самое верное: применять ту библиотеку, которая всё это реализует без MFC. AG>Мы обычно применяем OTLv4 для всех наших MFC проектов:
AG>http://otl.sourceforge.net/otl3.htm#toc AG>http://otl.sourceforge.net/otl3_compile.htm AG>http://otl.sourceforge.net/otl3_examples.htm
AG>Библиотека очень удобная и легкая, в отличие от монстроидальных классов MFC для работы с БД. AG>Представлена библиотеке — в виде одного заголовочного файла, компилируется — под какую угодно БД (но, естественно для Windows). AG>Работать с ODBC для MS SQL Server с этой библиотекой — легко и приятно. AG>Если что нужно — спрашивайте здесь (скину примеры)!
AG>Здесь очень простая connection string (не надо возиться с MFC-строкой соединения): AG>пример строки: AG>sa/12345@ODBCDSNName AG>где: AG>"sa" — это логин (стандартный для MS SQL Server) AG>"12345" — это пароль AG>"ODBCDSNName" — имя ODBC источника данных.
это DSN имя?
AG>P.S. Вообше-то правильнее было бы именно работать через ODBC-DSN источник данных, а не пытаться уйти от него. AG>Если у Вас несколько БД, то создайте несколько ODBC-DSN источников (по каждому для соответствуюшей базы).
похоже это лучший выход. Проект довольно разбухший, все перерисовывать, заново тестировать...
Спасибо!
Здравствуйте, уважаемый gok, Вы писали:
AG>>Здесь очень простая connection string (не надо возиться с MFC-строкой соединения): AG>>пример строки: AG>>sa/12345@ODBCDSNName AG>>где: AG>>"sa" — это логин (стандартный для MS SQL Server) AG>>"12345" — это пароль AG>>"ODBCDSNName" — имя ODBC источника данных. gok>это DSN имя?
Да, это имя Data Source Name!
Здесь три имени DSN — выделены на рисунке.
AG>>P.S. Вообше-то правильнее было бы именно работать через ODBC-DSN источник данных, а не пытаться уйти от него. AG>>Если у Вас несколько БД, то создайте несколько ODBC-DSN источников (по каждому для соответствуюшей базы). gok>похоже это лучший выход. Проект довольно разбухший, все перерисовывать, заново тестировать... gok>Спасибо!
Уважаемый gok, я прекрасно Вас понимаю
Вот сидит где-то далеко дядька AlexGin, и даёт советы! Мне же, если следовать этим советам, надо много переписывать и тестить...
Однако, если проект серьёзный, эти трудо-затраты окупятся сторицей!
Так, например, у нас БД в 2GB — где более 300000 картинок (MS SQL Server 2008), используя OTLv4 грузится в память, не на самом топовом железе, примерно около 2-х секунд. Это всё делается в MFC приложении.
P.S. Отмечу, что проект OTL — постоянно развивается (в отличие от библиотеки MFC) и автор, Сергей Кучин,
известный специалист по базам данных, непрерывно поддерживает его up-to-date.
На сегодняшний день, библиотека OTL поддерживает все самые современные тенденции в мире СУБД.
Я отвлечённо от вопроса рекомендую просто тупо не использовать слой MFC для работы с СУБД (БД).
Он очень плохой и негибкий, и даёт очень мало функционала.
Возьмите любую стороннюю библиотеку для работы через ODBC или для работы с вашей БД напрямую
через их нативные API, будет полезнее в итоге для вашего проекта раз в 10 в итоге.
При этом чем раньше вы это сделаете, тем будет легче переходить.
А Екселя нет?
MZ>>Он очень плохой и негибкий, и даёт очень мало функционала. AG>Да, это именно так: MFC не пердназначается для решение задач работы с БД, так слой работы с БД очень слабый
MZ>>При этом чем раньше вы это сделаете, тем будет легче переходить. AG>+100500
Полностью согласен. Переходим от МФС. Есть такая штука в шарпе NHibernate, не пробовали? Не думаю она лучше OTL.
Спасибо!
Здравствуйте, gok, Вы писали:
gok>Полностью согласен. Переходим от МФС...
Вы тогда OTL применили?
Успешно?
gok>Есть такая штука в шарпе NHibernate, не пробовали? Не думаю она лучше OTL. gok>Спасибо!
Нет, не пробовал.
Не уверен, что это для меня и моих проектов актуально.
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, gok, Вы писали:
gok>>Полностью согласен. Переходим от МФС... AG>Вы тогда OTL применили? AG>Успешно?
Успешно, только в тесте.
gok>>Есть такая штука в шарпе NHibernate, не пробовали? Не думаю она лучше OTL. gok>>Спасибо! AG>Нет, не пробовал. AG>Не уверен, что это для меня и моих проектов актуально.
Там вообще без ДСН, маппирование таблиц напрямую в код без МС посредников.
