Вылезла проблема, которую и не ожидала.
Установила sqlite3, а также драйвер odbc.
Машина, на которую ставлю программу, такая же, как у меня дома ( дома все работает).
Но на рабочей машинке появляется сообщение
No usable Sqlite3 dll found
Пробовала переустановить sqlite, ничего не изменилось.
И тут я зависла, я не знаю, что делать дальше.



Исправлено 1 раз(а). Последнее : tata, 23.04.19 12:56

Попробовать от админа поставить

Сам файл есть в системе?
Если нету - принести с домашнего компа.
Если есть - могут "мешать" другие программы, попробовать их отключить на время.

Я так и не поняла, что это было, наверное, просто я тетеря криворукая.
Снести все и поставить заново- и все работает как часы.
Уф, можно забыть об одной проблеме.
Пишу, если кому понадобится, а может, даже себе. )))
Ставить sqlite3.dll через cmd. Exe
Затем ставить odbc- драйвер для SQLite.
На 32 и 64-разрядных машинах драйвера разные.

Неправильно работает селект.

lcQuery1="select D.REGNUMBER, F.NAME, d.USER_NAME, FILE_NAME, d.RECEIVER_RECIPIENT, d.name as name1, DateTime(Creation_Time, 'unixepoch', 'localtime') as fu_dt ;
from document D, attachment A, Folder F "
lcquery2="where d.parent_id = f.id and A.PARENT_ID = D.ID and FILE_NAME <> 'blank.txt' and file_name not like '%.p7s' "
LCQUERY=LCQUERY1+LCQUERY2
Выдает список либо только входящих, либо исходящих (видимо, зависит от таблицы - какова первая запись в ней, те и тащит.
Попробовала inner join, ругается на ошибку селекта.
Устала я уже. Может, кто видит, в чем ошибка, дайте знать.

lcQuery1="select D.REGNUMBER, F.NAME, d.USER_NAME, FILE_NAME, d.RECEIVER_RECIPIENT, d.name as name1, DateTime(Creation_Time, 'unixepoch', 'localtime') as fu_dt ;
from document D, attachment A, Folder F "
lcquery2="INNER JOIN FOLDER F ON F.ID = D.PARENT_ID where A.PARENT_ID = D.ID and FILE_NAME <> 'blank.txt' and file_name not like '%.p7s' "
LCQUERY=LCQUERY1+LCQUERY2

1) Ты не привела само сообщение о ошибке.
2) У тебя не указан алиас для поля FILE_NAME.
3) Наполни курсоры тестовыми данными, чтобы можно было хоть что-то пощупать.
4) Перепиши условия соединения таблиц в части WHERE на условия соединения в LEFT/INNER JOIN - как по мне, так информативность куда выше.

должно быть так:

sphinx

INNER JOIN FOLDER F ON F.ID = D.PARENT_ID where A.PARENT_ID = D.ID and FILE_NAME <> 'blank.txt' and file_name not like '%.p7s' "

должно быть так:

INNER JOIN FOLDER F ON F.ID = D.PARENT_ID AND A.PARENT_ID = D.ID WHERE FILE_NAME <> 'blank.txt' and file_name not like '%.p7s' "

Я уже и так пробовала - не помогает.

lcQuery1="select D.REGNUMBER, F.NAME, d.USER_NAME, FILE_NAME, d.RECEIVER_RECIPIENT, d.name as name1, DateTime(Creation_Time, 'unixepoch', 'localtime') as fu_dt ;
from document D, attachment A, Folder F "
lcquery2="INNER JOIN FOLDER F ON F.ID = D.PARENT_ID and A.PARENT_ID = D.ID where FILE_NAME <> 'blank.txt' and file_name not like '%.p7s' "
LCQUERY=LCQUERY1+LCQUERY2

А ошибка одна - нерабочий селект.

WAIT WINDOW "Выполняется запрос " TIMEOUT 2
IF SQLEXEC(lnHandle,lcQuery, "MyCursor", acount)>-1
MESSAGEBOX("Выбрано "+STR(acount(1,2),10)+ " записей", 64,1000)
ELSE
MESSAGEBOX("Ошибка!")
ENDIF

Самое смешное - в путевых листах точно такой же запрос работает как часы.

SELECT plist
nput=plist.nump
nmark=plist.anum
SELECT Plist.nump, Plist.nump1, Plist.anum, Plist.drivercode, Plist.datap, ;
Plist.spid_beg, Plist.spid_end, Plist.gorod, Plist.trassa, Plist.posder, ;
Plist.probeg, Plist.zima_leto, Plist.b_marka, Plist.b_cost, Plist.b_beg, ;
Plist.b_end, Plist.b_rasx, Plist.b_zapr, Plist.b_norma, Plist.avtz, Plist.datz, ;
Plist.prz_del, Marka.marka, Marka.gosnom, Marka.godv, Marka.idnum, Marka.kaprem, ;
Marka.condit, Driver.fios, Driver.udost, Driver.classn, Driver.tablenum, Plist.b_pere, Plist.b_sum ;
FROM plist!plist ;
INNER JOIN plist!driver ON ?Driver.code = Plist.drivercode INNER JOIN plist!marka ON ?Plist.anum = Marka.anum ;
WHERE Plist.nump = ( nput ) AND Plist.anum = ( nmark );
INTO CURSOR pl2

Убери условия, проверь, что работает без них. Потом добавь по одному.

Убери из запроса


Без условий и поля fu_dt запрос должен работать. Добавь формирование поля - посмотри не ломает ли запрос это добавление.

> точно такой же запрос работает:
FROM plist!plist ;
INNER JOIN plist!driver ON ?Driver.code = Plist.drivercode ;
INNER JOIN plist!marka ON ?Plist.anum = Marka.anum

а у тебя не так
from document D, attachment A, Folder F ;
INNER JOIN FOLDER F ON F.ID = D.PARENT_ID and A.PARENT_ID = D.ID

может так?
from document D ;
INNER JOIN FOLDER F ON F.ID = D.PARENT_ID ;
INNER JOIN attachment A ON D.ID = A.PARENT_ID

и INNER-ы поначалу можно убрать, чтобы посмотреть на NULL-значения всякие, хотя по умолчанию фик знает какой "JOIN" устанавливается

Без твоих данных сказать почему выдаёт не тот результат который ты хочешь - невозможно.
Синтаксически вариант
выглядит корректным, и разницы с запросом с inner join не имеет. Условия соединения имеются.
Вариант с inner join, конечно же, должен выглядеть вот так:
Но повторюсь - семантически (по смыслу) эти два запроса одинаковы.
Отсутствие уточняющего алиаса перед полем FILE_NAME не критично, если это поле имеется только в одной из 3 таблиц.

Не видя структуры БД можно лишь догадываться - является ли поле id в таблицах document и folder первичным ключом (т.е. уникально), является ли поле PARENT_ID в таблице attachment внешним ключом на таблицу document, а поле PARENT_ID в таблице document внешним ключом на таблицу Folder.

Для оформления текста запросов к внешней БД советую использовать команду TEXT ... ENDTEXT (возможно с флагами, если внешняя СУБД не понимает переводов строки и лишних пробелов в тексте запроса) - тогда сам текст запроса сразу в читаемом виде будет, а не так как у тебя.

Можешь для отладки сделать сначала 3 отдельных запроса и вынуть все данные из этих 3 таблиц в фоксовые курсоры, а потом уже исполнить в собственно фоксе запрос объединяющий и отсеивающий данные. Если и после этого будет непонятно, то скинь данные этих 3 курсоров в постоянные таблицы, анонимизируй данные, обрежь до разумного минимума (по 5-6 записей в каждой из таблиц будет вполне достаточно - только проследи чтобы это были именно связанные данные - скажем 2-3 письма, их аттачи и папки в которых они находились) и приложи тут в виде архива. В идеале, конечно, было бы тестовые данные предоставить в виде create cursor + insert команд, но хотя бы архивом...

> from document D, attachment A, Folder F
where d.parent_id = f.id and A.PARENT_ID = D.ID
and FILE_NAME <> 'blank.txt' and file_name not like '%.p7s'

А как фокс (или драйвер) вычленяет собственно связи между таблицами D,A,F (d.parent_id = f.id and A.PARENT_ID = D.ID) из текста WHERE? В этом драйвере есть ИИ?
Мтк, без JOIN-ов он это не сумеет...

Доб. Аа, наверное вот как надо понимать первое выражение:
- строятся все возможные комбинации записей D,A,F (декартово произведение?), получится очень большая таблица
- в этом произведении отбираются записи, удовлетворяющие выражению WHERE
Тогда результат действительно будет таким же, что с JOIN-ами...



Исправлено 1 раз(а). Последнее : of63, 13.05.19 09:38

так работает любой скл сервер - забота оптимизатора не делать глупостей типа промежуточного результата на 100500 записей из которого потом реальных 10 "связанных" взять. Но "логически" это выглядит именно так.
P.S. join это всего лишь синтаксис, это НЕ указание движку делать какие-то set relation или тому подобное управление тем КАК исполняется запрос - это лишь описание того ЧТО от запроса требуется. Потому то они и эквивалентны - что join что вариант с перечислением таблиц через запятую а условий соединения в where.





Исправлено 1 раз(а). Последнее : Igor Korolyov, 13.05.19 23:38

Ну вот, вроде похоже на правду получается.
Однако проблемы на этом не заканчиваются.
В некоторых полях regnumber_string стоит номер в виде N 123456,
а в некоторых %d.
Причём это в самой таблице так.
Я теперь встала с этим %d, может, кто-то знает, что это такое и как ЭТО превратить в нормальный номер?
Выглядит как ссылка на что-то.



Исправлено 1 раз(а). Последнее : tata, 14.05.19 23:29

Может тупо номер соответствует дню месяца? И тогда выдёргивается strftime('%d', НеизвестнаяМнеДата).