Есть связанные таблицы, в "ведомой" нет записей, которые есть в "главной". Пока на ум приходит что-то типа

IF !FOUND()
thisform.Label1.Value = 'Запись находится в архиве'
ENDIF

И повесить на InteractiveChange...

Подскажите, как вы делали?

Спасибо!

Ну, Caption наверное ... а вы relation используете? или какой перезапрос из подчиненной?

Relation.

Думается, что для того, чтобы обсуждение не получилось на 12 страницах, надо четко оговорить, что именно интересует ТС:
а) текст сообщения
б) где разместить сообщение
в) каким размером, шрифтом, цветом и т.п. выводить сообщение
г) посредством какого кода выводить сообщение

Возможно, ТС интересует только один из перечисленных пунктов. А, возможно, несколько или вообще все пункты от а) до г). Или даже еще какие-нибудь пункты д),е), ж) и т.д.

тов. Simple777 как всегда за философский подход к делу )))

по-поводу реляций - я хоть и любительствую, но где-то лет несколько назад отказался от этого механизма ... даже сейчас и не скажу почему именно, может потому что спрыгнул с dbf в кач-ве бд, или что-то не устраивало - честно не помню. Предпочитаю в таких случаях подзапросы с соотв. параметрами.

Как вариант - а ведь можно сразу при построении курсора сразу отдельным полем вывести кол-во подчиненных записей.

счас ради интереса глянул:
пусть cM - мастер, cD - деталь, связал по SET RELATION ... ну да, банальный FOUND('cD') кажет нашлось чего или нет ))))

тока вот не понял при чем тут InteractiveChange ... вроде ж просто по записям мастера двигаетесь, тут наверное на AfterRowColChange повесить



Исправлено 1 раз(а). Последнее : AndyNigmatec, 09.03.17 22:51

AndyNigmatec
но где-то лет несколько назад отказался от этого механизма

А я и не писал, что люблю этот механизм. Просто есть ПО, которое надо переложить с FPD 2.6 на VFP 9.0, причем организационно-политически на СУБД типа Oracle переводить нельзя. Вот и приходится пользоваться тем, что есть, прежде всего связанными по relation таблицами. Я же не предлагаю подискутировать, какой подход лучше, а спрашиваю, кто и как делал по описанной проблеме.

AndyNigmatec
ну да, банальный FOUND('cD') кажет нашлось чего или нет

Ага, значит правильно думал. Да, только область указать надо.

AndyNigmatec
тут наверное на AfterRowColChange повесить

Я на память писал, когда увидел AfterRowColChange - сообразил на предмет напрашивающегося перевода.

Ок. Завтра так и сделаю.

Ну так вы сами и ответили на свой впрос ))) - и found пожалуй самый простой и незатратный способ, сам бы наверное так и поступил без лишних углублений в теорию



Исправлено 1 раз(а). Последнее : AndyNigmatec, 09.03.17 23:11

AndyNigmatec
тов. Simple777 как всегда за философский подход к делу )))

Он цицеронит и сократат. ;)

AndyNigmatec
Ну так вы сами и ответили на свой впрос

Я просто не мог проверить свою версию, решил у ребят спросить. Ну и вроде тормозов быть не должно.

А сравнивать их по reccount() не подходит?

Found подразумевает, как минимум locate, а, значит, задержки в работе при каждом "дергании" столбца грида. К тому же сравнивать, я так понимаю, надо ведб не по одному полю таблицы, а по полной аутентичности или нет?



Исправлено 1 раз(а). Последнее : Chemberzhy, 09.03.17 23:15

Но ведь "в лоб" все равно FPD на VFP перевести не получится - может лучше переписать заново - или это нереально по времени? или нереально скучно

Chemberzhy
А сравнивать их по reccount() не подходит?

- не, reccount покажет полное кол-во записей в подчиненной

Chemberzhy
Found подразумевает, как минимум locate, а, значит, задержки в работе при каждом "дергании" столбца грида. К тому же сравнивать, я так понимаю, надо ведб не по одному полю таблицы, а по полной аутентичности или нет?

никаких locate там не нать - там же реляция готовая уже, я ж написал - быренько проверил - никаких лишних движений - только found-а достаточно

Если они связаны как 1-к-1-или-0, то просто запросом с LEFT JOIN - по наличию NULL в полях из "подчинённой" таблицы можно судить о том что подходящая запись не нашлась. Если это вообще чисто информационно, то можно даже через CAST(NVL(какое_то_значимое_поле, "Запись находится в архиве") AS C(50)) соорудить вычисляемое поле с текстом и показывать его пользователю.
Если 1-ко-многим, ну по количеству записей в подчинённом курсоре после его перезапроса. Хотя странновато это - и так будет видно в подчинённом гриде что записей нет...

Пользоваться в визуальной части (в гридах особенно) SET RELATION я бы не стал даже за очень большие деньги, ибо это очень уж г*венно работает

sphinx
Как элегантно/красиво вывести сообщение о отсутствующей записи?

Кстати, если записи отображаются случайно таки в гриде в принципе можно сделать еще элегантнее, без текстбокса, а через динамику этого столбца - т.е. вместо отсутствующих записей там будет висеть надпись, можно даже окрашенная другим цветом.





Исправлено 1 раз(а). Последнее : Crispy, 10.03.17 07:08

Crispy
Кстати, если записи отображаются случайно таки в гриде в принципе можно сделать еще элегантнее, без текстбокса, а через динамику этого столбца - т.е. вместо отсутствующих записей там будет висеть надпись, можно даже окрашенная другим цветом.

И такая идея была.

На практике получилось следующее: главная таблица - это справочник продукции, часть ее отсутствует. Отсутствующие и предполагалось показать, когда по подчиненной идешь. Но.. я просто наложил фильтр:

SET FILTER TO FOUND('алиас')

Chemberzhy
Found подразумевает, как минимум locate

На кой он черт, если

AndyNigmatec
там же реляция готовая

Igor Korolyov
Если они связаны как 1-к-1-или-0, то про
сто запросом с LEFT JOIN - по наличию NULL в полях из "подчинённой" таблицы можно судить о том что подходящая запись не нашлась.

Игорь, SQL-запросы к серверным DBF работают крайне медленно (почему и пришлось использовать связку SEEK ключ + COPY TO файл WHILE условие.. но это совсем другая история). FOUND() работает быстро, код городить не нать.

Медленно работают неоптимизированные запросы и глупые идеи показа 100500 записей в гриде с листанием оного до посинения (и всякими "инкрементными поисками" - для хоть какого-то сокрытия ущербности самого подхода).
Всё прочее "на dbf-ах" при использовании SQL работает ничуть не хуже SEEK+COPY ... WHILE, не говоря уж про убогие SET RELATION и SET FILTER. Который, к слову, до 9-го фокса при работе в гриде НЕ оптимизируется и даёт тормозов по полной программе. А уж как там оптимизируется условие FOUND('другая таблица') - это вообще разговор отдельный...