|
Выяснение текущего количества записей в запросе к DB2
|
|||
---|---|---|---|
#18+
Доброго времени суток! Столкнулся с такой задачей, нужно при SQL запросе выяснить текущее значение reccount() в курсоре результата. Цель - рабочий ProgressBar Решил сделать так: x3=SQLEXEC(x1 ,"SELECT COUNT(*) AS nCnt FROM DB2INST.x2 x2 WHERE RETRN() =TRUE",[qSQLP]) function RETRN *// Действия с прогрессбаром return .T. endfunc Не хочет он его отрабатывать и все, x3 = -1 ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2010, 06:17 |
|
Выяснение текущего количества записей в запросе к DB2
|
|||
---|---|---|---|
#18+
Прошу прощения, не тот SQL вставил x3 = SQLEXEC(x1 ,"SELECT * FROM DB2INST.x2 x2 WHERE RETRN() =TRUE",[qSQLP]) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2010, 07:03 |
|
Выяснение текущего количества записей в запросе к DB2
|
|||
---|---|---|---|
#18+
Filka13, а как вы собрались на стороне DB2, которая собственно запрос и обрабатывает, выполнять фоксовую функцию? Функция на Вашем компе, сервер на другом компе, но выполяться должны вместе? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2010, 09:49 |
|
Выяснение текущего количества записей в запросе к DB2
|
|||
---|---|---|---|
#18+
Да... Что то я сглупил... Вы конечно же правы. Буду дальше думать как же быть... и как все же реализовать сие. БД Огромная, находится далеко, тормозит при загрузки жутко, так что реализовать прогрессбар необходимо. Огромное спасибо. Придется сделать выборку с LIMIT и от него уже отталкиваться. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2010, 09:59 |
|
Выяснение текущего количества записей в запросе к DB2
|
|||
---|---|---|---|
#18+
Filka13реализовать прогрессбар необходимо.Именно прогрессбар и никак иначе? А сервер умеет сообщать количество обработанных записей до окончания обработки? То есть он их еще не видел, но уже знает их количество? И умеет отдавать эти знания во время выполнения запроса? Или таки он узнает количество обработанных (а не подлежащих обработке) записей только после выполнения запроса? Может таки не городить ерунду и заняться индикацией выполнения процесса в виде чего-то бесконечно движущегося, а не пытаться узанть заранее то, чего нельзя узнать заранее? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2010, 11:27 |
|
Выяснение текущего количества записей в запросе к DB2
|
|||
---|---|---|---|
#18+
Может и умеет, честно я лишь недавно начал работать с серверами DB2 и на что он способен не знаю. Количество записей в таблице я вычислил..., это было не сложно..., а вот с остальным проблемы. Может и бесконечность сделать... Но наверное я все же остановлюсь на прогрессбаре, так как лучще уж видеть наглядно как качаются более миллиона записей В целом, это заплатка, так как подгружаются данные на другой сервер DB2 :) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2010, 09:55 |
|
Выяснение текущего количества записей в запросе к DB2
|
|||
---|---|---|---|
#18+
Filka13Но наверное я все же остановлюсь на прогрессбаре, так как лучще уж видеть наглядно как качаются более миллиона записей Для этого не нужен сервер. Ибо он наврят ли знает сколько записей клиент забрал. Но это точно знает клиент. Вот на клиенте и считайте полученные записи и сравнивайте с общим количеством (если оно у Вас есть). Вот тогда и прогрессбар можно будет сделать. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2010, 09:59 |
|
Выяснение текущего количества записей в запросе к DB2
|
|||
---|---|---|---|
#18+
проходящий.Filka13Но наверное я все же остановлюсь на прогрессбаре, так как лучще уж видеть наглядно как качаются более миллиона записей Для этого не нужен сервер. Ибо он наврят ли знает сколько записей клиент забрал. Но это точно знает клиент. Вот на клиенте и считайте полученные записи и сравнивайте с общим количеством (если оно у Вас есть). Вот тогда и прогрессбар можно будет сделать. Есть идеи как во время выполнение SQL запроса обратится к уже выбранным записям? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2010, 11:53 |
|
Выяснение текущего количества записей в запросе к DB2
|
|||
---|---|---|---|
#18+
Filka13Есть идеи как во время выполнение SQL запроса обратится к уже выбранным записям?К выбранным клиентом? Если это асинхронный запрос, то выбранные записи накапливаются в курсоре. Если запрос синхронный (что для выборки более миллиона записей как-то не очень), то ничего нельзя сделать до окончания выполнения запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2010, 12:01 |
|
Выяснение текущего количества записей в запросе к DB2
|
|||
---|---|---|---|
#18+
Filka13Есть идеи как во время выполнение SQL запроса обратится к уже выбранным записям? Выполнять запрос асинхронно. Т.е. установить свойство Код: plaintext
В этом случае можно выполнять обработку в процессе подкачки данных с сервера. В том числе и количество полученных записей, используя 4 параметр функции SQLExec() - acountInfo в VFP9 Пример можно посмотреть здесь http://forum.foxclub.ru/read.php?29,206294,207017#msg-207017 Только следует иметь в виду, что работа в асинхронном режиме имеет свои особенности. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2010, 12:06 |
|
Выяснение текущего количества записей в запросе к DB2
|
|||
---|---|---|---|
#18+
проходящий.Filka13Есть идеи как во время выполнение SQL запроса обратится к уже выбранным записям?К выбранным клиентом? Если это асинхронный запрос, то выбранные записи накапливаются в курсоре. Если запрос синхронный (что для выборки более миллиона записей как-то не очень), то ничего нельзя сделать до окончания выполнения запроса. Не совсем так. Пока происходит Fetch данных в курсор при асинхроном чтении данных с сервере, сам курсор, куда делается Fetch (который указан в команде SQLEXEC), вам не доступен! Придеться и на сервере разбивать данные на части и по частям их доставлять клиенту. Вот тогда можно будет обрабатывать предыдущий набор данных, пока читается следующий. Вот тут я приводил пример: http://vfox.kristall.ru/sql_async.html С уважением, Алексей ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2010, 12:46 |
|
|
start [/forum/topic.php?fid=41&msg=36615020&tid=1585319]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
24ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
others: | 339ms |
total: | 437ms |
0 / 0 |