forum.clarionlife.net

Clarion 8.9661
База posgtresql

Таблица для результатов запросов
sqlfile FILE,DRIVER('ODBC','/JOINTYPE=''ODBC 3.0'' /NESTING=TRUE'),OWNER(glo:owner),NAME('sqlfile'),PRE(sql),BINDABLE,CREATE,THREAD
Record RECORD,PRE()
mystr CSTRING(200) !
r01 STRING(50) !
.......................................
r20 STRING(50) !
END
END

Выполняю запрос :
sqlfile{PROP:SQL} = 'SELECT kod_pe,gos_nom from avto'
все ОК.
На запрос:
sqlfile{PROP:SQL} = 'WITH q(q1,q2) as (SELECT kod_pe,gos_nom from avto) (select * from q)'
после NEXT(sqlfile)
получаю:
fileerrorcode =
fileerror =
errorcode = 33
error = Record Not Available
SmartSniff показывает, что запрос выполнен и данные с сервера пришли, а Clarion их не видит.
Может кто знает как быть?

Добрый день!
Я не использую posgtresql, но по аналогии с SQL,
я бы выполнил Ваш запрос непосредственно в среде posgtresql и посмотрел бы результат.


Алексей

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

Попробуйте посмотреть, что покажет trace.exe

Добрый день!
Я не сомневаюсь в мощности языка.
Я сомневаюсь в результате его работы: что конкретно в данном случае явлется результатом выполнения запроса.

Алексей

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

Добрый день!
Мы с Вами как китаец с чукчей разговориваем (ничего личного )
Я спрашиваю про результат выполнения запроса, а Вы отвечаете - да они необходимы.
Начнем сначала:

На запрос:
sqlfile{PROP:SQL} = 'WITH q(q1,q2) as (SELECT kod_pe,gos_nom from avto) (select * from q)'
после NEXT(sqlfile)
получаю:
fileerrorcode =
fileerror =
errorcode = 33
error = Record Not Available

Ошибка может возникать, в том числе, по причине:
1. Действительно результатом выполнения запроса - нет записей
2. Структура данных , полученных в результате выполнения запроса, не соответствует буферу sqlfile
и т. д.
Поэтому я и предлагал Вам выполнить запрос в среде СУБД (без Клариона),
и посмотреть какие данные получаются в результате.

Отсюда и начать "пляски с бубном"

Алексей

Ничего не помогло, но в процессе экспериментов вышел на другое решение, которое работает.
SELECT t.kod_pe, t.gos_nom
FROM
(select kod_pe,gos_nom
FROM avto) AS t
order by kod_pe;
Тоже готовим данные в промежуточной таблице (в данном случае 't') и получаем из нее результат.
Более сложный пример с двумя промежуточными таблицами (t1 и t2). Выборка из одной таблицы (tablo_out) с разными фильтрами.
SELECT t1.date_, t1.nomer, t1.s_o, t2.s_i
FROM
(select date_,nomer,oper_type,count(*) AS s_o
FROM tablo_out
where date_=77444 and oper_code=3 and oper_type=2
group by date_,nomer,oper_type) AS t1,
(select date_,nomer,oper_type,count(*) AS s_i
FROM tablo_out
where date_=77444 and oper_code=3 and oper_type=3
group by date_,nomer,oper_type) AS t2
WHERE t2.nomer=t1.nomer and t2.date_=t1.date_;
Применим и вариант с одной промежуточной таблицей с выборкой из нескольких таблиц.

Всем привет!
6.3, (ODBC) PostgreSQL 9.5.4
(да, pgSQL увидел "живьем" несколько дней назад)
надо синхронизировать данные файлов (Dat) с данными таблиц на сервере, сгенерил простенькую программку для проверки и перезаписи данных (loop-next, insert|update|delete, вообщем все просто по рабоче-крестьянски и без prop:sql...), но "неожиданно" все медленно , скорость обработки просто удручает, т.к. например на MS SQL все это работало б очень быстрее, но тут надо именно на PostgreSQL.
Есть ли у кого наработки, "волшебные пилюли", или только через скрипты можно ускориться?

А что именно медленнее? Уже был здесь, кстати, баттл по поводу скорости SQL. Например, нельзя для SQL делать set(File), потом next(File), и т.д.

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

посмотрел код, упростил просмотр при отборе "кандидатов" на обработку - залетало)
пошел на автобус

всем привет!
решил апнуть - тем, кто утомился с pgadmin 3, посмотрите http://dbeaver.jkiss.org/docs/features/

kreator писал(а): А что именно медленнее? Уже был здесь, кстати, баттл по поводу скорости SQL. Например, нельзя для SQL делать set(File), потом next(File), и т.д.

вообщем "велосипед" - начал формировать и отправлять инструкции (insert|update|delete) SQL порциями для обработки сразу больше чем одной записи - стало быстрее

пока такой вопрос у меня образовался, сразу оговорюсь, что тонкостей не знаю, мое дело в этом проекте - записать данные на один сервер pgsql и при необходимости считать на другом.
задача - очень быстро "зеркалировать" схему с кучей табличек между 2 серверами pqsql,
чел, который это обеспечивает, навесил триггеров и когда мои программы пишу на сервер небольшие порции данных, все быстренько обновляется и на другом сервере (<->), но как только порция данных увеличивается - до нескольких десятков тысяч записей, у меня из программы уходят инструкции на 1й сервер за миллисекунды/секунды/иногда за единицы минут (зависит от размера/формата полей в записях, вообще если много идет обновл. данных то в зависимости от формата файлов успешно через prop:sql порциями по 100/200/500 записей за раз отправляется, возможно и большими, но при увеличении размера порции через некоторое время падает скорость отправки, ну и проверять постоянно надо - вдруг "загрубил" и вышел за границы - сервак не примет такой кусман... ) и на 1м сервере все ок, но вот на другом (условно 2м) сервере, чтобы увидеть эти новые данные... приходится идти ставить кофе/выпить его/вымыть посуду/сходить почитать http://forum.clarionlife.net/ , атас вообщем... - по условию надо быстрее все получать на 2м сервере, да и ожидалось что будет ОЧЕНЬ быстро
Чел намекает "у меня все ок", а ты сам виноват - много данных - правь СВОЙ алгоритм и пересылай меньше мусорных данных... Алгоритм-то я вычищу... в очередной раз , но по факту - действительно настолько МЕДЛЕННО идет синхронизация данных между серверами PostgreSQL? или пора ... чела, долго и вдумчиво, что бы он начал шевелиться?

up - порядка 50000 +/- 1000 записей - и всё, "замерзает" надолго...