MasterZivKPOKODILВ общем, как подключится из QT c++ к таблице из базы данных VFP на локальной машине.


Как к источнику ODBC. Через ODBC -"SQL драйвер" , в QT такой есть. При этом ODBC -драйвер будет сторонний, не от QT (их вообще в QT нет), рекомендую использовать драйвера от MSOffice.

Учти, что драйвера эти сами НЕ БЕСПЛАТНЫЕ, и существуют они только на Windows.
Есть старый и очень ограниченный VFP ODBC драйвер:

http://download.microsoft.com/download/vfoxodbcdriver/Install/6.1/W9XNT4/EN-US/VFPODBC.msi

MasterZivKPOKODILБыло сказано, что следует использовать Microsoft OLE DB Provider.


QT не поддерживает OLE DB вообще, на сколько я знаю. Оно и понятно -- ODBC -- cross platform, OLE DB -- нет.
Ну почему не поддерживает? Очень даже поддерживает! OLE DB это обычные COM сервера (VfpOleDb ProgIds: "VFPOLEDB.1", "Vfpoledb.ConnectionPage.1", "VFPOLEDB.ErrorLookup.1"). А для работы с COM серверами в Qt есть классы QAxObject и QAxWidget. Через них и можно «достучаться» до любого COM сервера, в том числе OLE Automation. А будет или нет это поддерживаться в других ОСях, это уже другой вопрос. Qt вполне себе может задействовать непереносимые плюшки конкретной ОСи. Обычно в таких случаях советуют выносить непереносимый код в отдельный модуль и писать его разные версии для разных ОСей.

MasterZivЭтот в смысле того, что есть поддержка в SQL-подсистеме QT, можно использовать во VIEW от QT, есть готовые модели,
можно показывать в таблицах данные и всё такое.
Если этого всего не нужно, то можно конечно и через OLE DB, и вообще через любую библиотеку для работы с DBF.

Как это делается (код) -- в QT есть примеры для работы с базами данных, берёшь любой и смотришь.
Вид БД при этом значения не имеет -- все СУБД для QT одинаковы из-за наличия слоя QT -драйверов для работы с БД.
Профессиональная работа с базами данных в Qt не слишком очевидна для непосвященных. Все доступные примеры сделаны по принципу «тяп-ляп». Даже в таких проектах как «Ананас» и «1L». Кроме этого, дается очень ограниченная установка, типа пользуйся стандартными драйверами БД в Qt (максимум потребуется собственная компиляция их), а все что вне этого считается недоступным по определению. Что есть явная глупость, так как Qt это не новый язык программирования, а всего лишь расширенная библиотека классов для С++.

MasterZivЯ думаю, что всё же OLE DB для использования в QT брать не стоит.
Всё же QT кроссплатформенный... Да и писать всю работу с БД придётся самому.
А так в QT -- выполняешь запрос и отдаёшь модели, к ней биндишь view -- и всё, готово.
Полагаю, это не совсем верный подход. Отдельные не кроссплатформенные модули можно делать версионными, тогда, когда это реально понадобится. А писать «всю работу с БД» самому не нужно.

Автор топика уже задавал подобный вопрос в ветке форума «Visual FoxPro» и я там ( http://www.sql.ru/forum/1051350/podkluchenie-k-vfp-iz-qt-c ) привел для него пример использования
COM сервера "VisualFoxPro.Application.9" (OLE Automation) в Qt-5.2, при наличии файлов vfp9.exe (загружается командой: vfp9.exe /regserver ) и vfp9enu.dll. Также нет никаких проблем перейти в Qt от outproc (exe) сервера к inproc (dll) серверу, как в С++, только проще.

Попутно замечу, что я получаю полноценный доступ к возможностям VFP при работе «клиента» в Qt. Т.е. я могу не только использовать графические возможности FoxPro (в Qt они нафик не нужны), но и компилировать и исполнять в рантайме VFP скрипты (prg-файалы). Можно воспользоваться также inproc сервером, тогда графика VFP будет недоступна, что не является существенным ограничением. А то, что VFP платен, не означает, что у него нет сторонников.

Еще следует сказать, что доступ у меня осуществляется к вариантному массиву данных VFP, полученных методом VFP RequestData(). При больших объемах данных загружаемых dbf-файлов, в этом случае, очень нерационально используется память. В этом случае нужно работать в виртуальном режиме. Такой режим Qt тоже поддерживает, почти по умолчанию (но об этом мало кто знает, многие думаю, что это невозможно). Его я реализовал в примере, который прикладываю здесь. К сожалению, для его нормальной работы требуется буферизация данных, которую я еще не успел реализовать, но зато я могу открывать несколько достаточно большие файлы (например, размером 500 МБ с двумя миллионами записей). Прокрутка идет медленно (без буферизации!), но зато можно легко «скакать» в любое место файла, тыкая в нужное место ползунком.

Как видим нестандартный подход работы с БД в Qt расширяет наши возможности ничуть не усложняя логику работы и код программы.

Прилагаю также бинарный файл, не забудьте указать путь на библиотеки Qt-5.2.

Модератор: Не надо этого делать.
Вложение удалено.

White OwlEmeryНу почему не поддерживает? Очень даже поддерживает! OLE DB это обычные COM сервера (VfpOleDb ProgIds: "VFPOLEDB.1", "Vfpoledb.ConnectionPage.1", "VFPOLEDB.ErrorLookup.1"). А для работы с COM серверами в Qt есть классы QAxObject и QAxWidget. Через них и можно «достучаться» до любого COM сервера, в том числе OLE Automation. А будет или нет это поддерживаться в других ОСях, это уже другой вопрос. Qt вполне себе может задействовать непереносимые плюшки конкретной ОСи. Обычно в таких случаях советуют выносить непереносимый код в отдельный модуль и писать его разные версии для разных ОСей.И это ты считаешь хорошим подходом? Берем кроссплатформенный фреймворк и делаем на нем не переносимое и трудное в поддержке приложение. Иначе как "извращение" я такой подход назвать не могу.
Точки зрения бывают разные и само по себе это не плохо. Один смотрит на Qt как на кроссплатформенный инструмент, другой как на мощную библиотеку классов С++. Чистая кроссплатформенность это всегда самоограничение. Никто не спорит, можно, когда нужно идти по этому пути, но иногда требуется ОСезависимая функциональность, кроссплатформеность при этом достигается версионностью отдельных модулей. Естественно так делать никто не заставляет, это уже вопрос практической необходимости.

White OwlEmeryПолагаю, это не совсем верный подход. Отдельные не кроссплатформенные модули можно делать версионными, тогда, когда это реально понадобится. А писать «всю работу с БД» самому не нужно. Тебе не кажется, что ты сам себе противоречишь?
Не кажется! Я знаю, что я хочу. А придирки к чужому стилю программирования никогда не воспринимал всерьез :) .

White OwlEmeryАвтор топика уже задавал подобный вопрос в ветке форума «Visual FoxPro» и я там ( http://www.sql.ru/forum/1051350/podkluchenie-k-vfp-iz-qt-c ) привел для него пример использования COM сервера "VisualFoxPro.Application.9" (OLE Automation) в Qt-5.2, при наличии файлов vfp9.exe (загружается командой: vfp9.exe /regserver ) и vfp9enu.dll. Также нет никаких проблем перейти в Qt от outproc (exe) сервера к inproc (dll) серверу, как в С++, только проще.Как человек писавший свои собственные драйвера для доступа к DBF (всех версий причем) я тебе ответственно заявляю: собственные драйвера намного проще и на пару порядков быстрее чем извращения с OLE Automation.
Очень спорное суждение! Я тоже писал собственный код доступа к dbf-файлам. См., например, «Создание и проецирование в память существующих DBF файлов» и «Программа сбора данных от нескольких клавиатурных устройств для учета рабочего времени» . Пытался даже разбираться в алгоритмах cdx-файлов , хотя это к теме данного разговора отношения не имеет, однако, мало иметь доступ на чтение-запись, желательно еще получить возможность использования всей функциональности конкретной СУБД. А это может обеспечить только COM и OLE, из сторонних процессов. Поэтому вопрос о «простоте» собственных драйверов очень сомнительный. Что до скорости, то OLE Automation обеспечивает вполне приемлемую скорость. Затыки если и наблюдаются, то по вине программиста.

Хорошо, возьмем MS SQL Server. Каким образом, можно управлять этим сервером из любого клиента? Может быть, ты меня поправишь, но я знаю только о доступе через COM сервер, например, через «ADODB.Command.6.0» (msado15.dll). Это вполне официальный доступ, рекомендуемый M$. Т.е. Мелкософт рекомендует всем «извращения с OLE», кто пользуется их SQL сервером «снаружи»?

EmeryКак видим нестандартный подход работы с БД в Qt расширяет наши возможности ничуть не усложняя логику работы и код программы.И это ты называешь "не усложненным"? ну-ну.[/quot]
В моем примере, код, обеспечивающий работу с dbf, средствами VFP занимает очень мало места. Куда уже меньше? Причем все очень просто и прозрачно. Замечу, что примеры приведенные мною (в этой ветке форума С++ и на ветке VFP), вы нигде не найдете в Интернете, ибо связкой Qt + VFP COM/OLE практически никто не занимается. Предвижу замечание, это, мол, никому не нужно. Однако в мире есть действительно много ненужных вещей, которыми действительно никто не занимается, а если тема интересна, хотя бы одному, то почему бы обратить на нее внимание? Вот автор топика задал свой вопрос не только здесь на форумах, но и на других сайтах, значит эта тема для него действительно важна.

MasterZivWhite Owl,

я в общем с тобой согласен.

кроме того, идея использовать сейчас бд на dbf файлах вообще достаточно сомнительна.
Дело в не dbf, как таковом. Это все равно, что говорить, что «идея использовать сейчас редакторы txt-файлов достаточно сомнительна». Мол, какой txt-формат, когда есть doc-файлы и масса других, более «прогрессивных». В нашем случае, это скорее демонстрация возможностей использования механизма COM/OLE в Qt. И если это не нужно лично Вам, то это не значит, что это ненужно никому.

В защиту использования dbf в Qt-клиентах, могу сказать, что эта связка очень простая, удобная, легкая и вполне работоспособная для небольших проектов. Вон 1С77 использовала самописный движок для работы с dbf-файлами и ее программа работает на многих предприятиях до сих пор. Задействие Qt и VFP драйверов может позволить написать аналог «семерки» в очень упрощенном виде. Так, не нужно писать собственный движок для dbf, нет нужды делать конфигуратор (для конечного решения), нет нужды создавать 1С-подобный язык программирования (вместо этого использовать либо Qt Script, либо возможность компилировать и запускать на выполнение в рантайме VFP-скрипты), систему отчетов, типа Moxel тоже можно не делать, а использовать возможности построения отчетов средствами Qt и VFP и т.д. и т.п. Я, конечно, не призываю никого заниматься этим проектом, но то, что он, в принципе, доступен даже одному человеку, это факт. Так что «сомнительность» Ваша это на любителя.

MasterZivда нет, есть еще драйвер odbc для fox pro от Microsoft.
Есть, но он очень ограничен по возможностям, потому малоинтересен.

MasterZivEmeryЕсть, но он очень ограничен по возможностям, потому малоинтересен.

Чем это он ограничен ?
Можно ли с его помощью скомпилировать и запустить на выполнение внешние prg-файлы? Как насчет мультипоточности?

MasterZivА OLEDB думаешь сильно лучше ?
Вы имеете в виду драйвер vfpoledb.dll? Может быть, и он тоже ограничен, не проверял. Но я имел в виду, прежде всего, возможность работы либо с файлами vfp9.exe /regserver + vfp9enu.dll, либо с runtime-библиотекой VFP: vfp9t.dll/ vfp9r.dll + vfp9renu.dll. Их возможностей более чем достаточно.

MasterZivА ещё вопрос -- в QT есть классы (модели) для поддержки работы с БД.
На сколько я помню, поддержки OLEDB там нет.
Ну, я уже писал, что OLEDB это COM сервер, а для COM серверов в Qt есть классы QAxObject и QAxWidget. Через них и работаем. Как? См. пример программы. Думаю, что вместо VFP таким образом можно подсоединиться и MS SQL Server (через msado15.dll и ему подобные)

MasterZivКак ты собираешься, советуя работу через OLEDB, интегрировать данные, полученные через OLEDB в подсистему QT для работы с БД?
В приведенных мною примерах (здесь и на ветке форума Visual FoxPro) механизм подобной работы продемонстрирован. В одном случае показан доступ к вариантному массиву данных VFP через метод RequestData (нерациональное расходование памяти), а в другом выбирается j-тое поле i-той строки выбранного dbf-файла, что необходимо для виртуального режима. Память при этом расходуется умеренно, dbf-файлы могут юзаться неограниченных размеров и в произвольном количестве, однако для увеличения скорости прорисовки экрана в QTableView нужна буферизация. Я думаю ее вскоре реализовать. Это будет двойной кольцевой буфер, состоящий из двух «полуколец». Прямого аналога в Интернете я не нашел, придется «изобретать велосипед» :) .

Итак, с dbf в Qt можно работать, как минимум, четырьмя способами: 1. Outproc сервер; 2. Inproc сервер; 3. ODBC-драйвер и 4. VFPOleDb-драйвер. Здесь реализован первый случай, ранее на чистом С++, второй случай. С драйверами пока не пробовал, но принципиальных проблем не вижу.

Да, есть еще самописный драйвер QDbf и программа qtDbf.exe (с исходниками), которые легко найти в Интернете. Но они обеспечивают только чтение / запись dbf-файлов, причем не очень корректно.

MasterZiv,

Мне кажется, что мы уже ведем ненужные разговоры. Каждый пишет те программы, которые ему нравятся. Или не пишет те, которые не нравятся. Зачем Вам переубеждать меня, а мне Вас?

MasterZivEmeryMasterZiv,

Мне кажется, что мы уже ведем ненужные разговоры. Каждый пишет те программы, которые ему нравятся. Или не пишет те, которые не нравятся. Зачем Вам переубеждать меня, а мне Вас?

Ну, как, а поговорить ?

Тогда, лучше сменить тему ибо «о foxpro не говори, о нем все сказано» :) .