Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
02.10.2004, 14:01
|
|||
|---|---|---|---|
|
|||
Произвольное предложение WHERE в REMOTE VIEW... |
|||
|
#18+
Всем привет! Вначале опишу то, что дано: есть справочник корреспондентов, состоящий из нескольких таблиц (предприятия; должности на этих предприятиях; сотрудники, занимающие эти должности и т.д.) Для отображения этой информации используецца несколько remote view. Некоторые из них обновляемые и это их достоинство не хочецца терять . Но данных ОЧЕНЬ много, посему если сразу все вываливать на клиента, то справочник работает очень долго. Посему хочу открывать справочник ПУСТЫМ, а потом пользователь сам укажет по каким критериям он хотел бы выбирать данные (отбор может проводицца по нескольким полям). Для отбора использую свой объект, который на выходе выдает строку вида: Код: plaintext Подскажите плиз, многоуважаемые, можно ли добицца следующей вещи: создать remote view (желательно ОБНОВЛЯЕМОЕ), которое бы выглядело примерно так: Код: plaintext 1. 2. где в качестве lcWhere можно было бы подставить вышеуказанную строку фильтра? ЗЫ если кто-то скажет, что данное view не будет обновляемым никогда, то оговорюсь, что это лишь пример, на самом деле есть remote view , выбирающие данные из одной таблицы и которые хочецца также параметризовать по нескольким произвольным полям этой таблицы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.10.2004, 23:28
|
|||
|---|---|---|---|
|
|||
Произвольное предложение WHERE в REMOTE VIEW... |
|||
|
#18+
2 ___DenisKa Эх, сложную ты очень тему поднимаешь :( Попробую лишь очень кратко описать как я это делаю: 1) RV пишется с условием WHERE 1=1. Дальнейшее как обычно - т.е. поля назначаются ключевыми, обновляемыми и т.д. 2) Пользуются следующие 2 функции: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. Как видишь реально работает SPT запрос (прямой запрос), но его курсор делается "обновляемым" - т.е. потом можно пользовать TableUpdate()/TableRevert() Вместо Requery() пользуется соответствующая функция. Use_RV() можно и вообще никогда не пользовать. У меня на формах в DE ложатся именно RV, только им ставится свойство Nodata - чтоб они данные не тянули. А уж по ходу инициализации формы - где-то там на Init формы или даже позже проводится их перезапрос по Requery_RV("alias", m.lcWhere). Ессно что в такой схеме проявляется проблема разрушения гридов (реально ведь курсор пересоздаётся а не "перезаполняется") - но как я надеюсь если ты уже дорос до столь серьёзных вопросов, то эта проблема тебя не должна беспокоить :) способы её решения общеизвестны... Posted via ActualForum NNTP Server 1.0 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
08.10.2004, 02:03
|
|||
|---|---|---|---|
|
|||
Произвольное предложение WHERE в REMOTE VIEW... |
|||
|
#18+
Как говорицца: автор"Все гениальное - просто!" © Посему я, не мудрствуя лукаво, решил, что я для выборки и отображения данных буду использовать прямые запросы, где построить динамическое предложение WHERE - как "конфетку у ребенка ..." ©, а вот для редактирования конкретного корреспондента (карточки его), будет вызывацца другая форма, специально под ето дело заточенная... Таким образом я убиваю 2-х зайцев: 1. я получаю гибкую, быструю и удобную для поиска форму для поиска и выбора справочника, где для поиска я собираюсь использовать свой чудо-алгоритм поиска с учетом индекса релевантности, ранее уже описанный мной в форуме по MS SQL (ссылку не приведу - давно дело было...) 2. я получаю гибкую, быструю и удобную для редактирования форму для редактирования. Ессно внешний вид у них будет координально отличацца, текущий внешний вид и функциональность убога и медленна, как и все универсальное... Тем не менее, огромное спасибо за ответ - интересное решение! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=41&mobile=1&tid=1595670]: |
0ms |
get settings: |
7ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
60ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 221ms |
| total: | 374ms |

| 0 / 0 |
