Clarion - PostgreSQL
Модератор: Andrew™
Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
-
- Посетитель
- Сообщения: 49
- Зарегистрирован: 18 Август 2005, 10:16
- Откуда: Пермь
- Контактная информация:
Clarion - PostgreSQL
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
Таблица для результатов запросов
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 их не видит.
Может кто знает как быть?
С уважением, П.Ялунин (PIT)
-
- Ветеран
- Сообщения: 390
- Зарегистрирован: 26 Август 2009, 12:41
- Откуда: Moscow
- Контактная информация:
Re: Clarion - PostgreSQL
Добрый день!
Я не использую posgtresql, но по аналогии с SQL,
я бы выполнил Ваш запрос непосредственно в среде posgtresql и посмотрел бы результат.
Алексей
Я не использую posgtresql, но по аналогии с SQL,
я бы выполнил Ваш запрос непосредственно в среде posgtresql и посмотрел бы результат.
Алексей
-
- Посетитель
- Сообщения: 49
- Зарегистрирован: 18 Август 2005, 10:16
- Откуда: Пермь
- Контактная информация:
Re: Clarion - PostgreSQL
В среде PostgreSQL запросы такого типа с созданием промежуточной таблицы выполняются прекрасно, причем и более сложные.
Приведенный пример очень простой.
Приведенный пример очень простой.
С уважением, П.Ялунин (PIT)
-
- Ветеран
- Сообщения: 390
- Зарегистрирован: 26 Август 2009, 12:41
- Откуда: Moscow
- Контактная информация:
Re: Clarion - PostgreSQL
Добрый день!
Я не сомневаюсь в мощности языка.
Я сомневаюсь в результате его работы: что конкретно в данном случае явлется результатом выполнения запроса.
Алексей
Я не сомневаюсь в мощности языка.
Я сомневаюсь в результате его работы: что конкретно в данном случае явлется результатом выполнения запроса.
Алексей
-
- Посетитель
- Сообщения: 49
- Зарегистрирован: 18 Август 2005, 10:16
- Откуда: Пермь
- Контактная информация:
Re: Clarion - PostgreSQL
Приведенный пример это чистый тест.
Необходимость в таких запросах возникает при выборке данных из нескольких таблиц с одновременным применением расчетов, которые в этом случае выполняет сервер и выдает только результаты в объеме намного меньшем, чем при вычислениях на рабочей станции.
Необходимость в таких запросах возникает при выборке данных из нескольких таблиц с одновременным применением расчетов, которые в этом случае выполняет сервер и выдает только результаты в объеме намного меньшем, чем при вычислениях на рабочей станции.
С уважением, П.Ялунин (PIT)
-
- Ветеран
- Сообщения: 390
- Зарегистрирован: 26 Август 2009, 12:41
- Откуда: Moscow
- Контактная информация:
Re: Clarion - PostgreSQL
Добрый день!
Мы с Вами как китаец с чукчей разговориваем (ничего личного )
Я спрашиваю про результат выполнения запроса, а Вы отвечаете - да они необходимы.
Начнем сначала:
1. Действительно результатом выполнения запроса - нет записей
2. Структура данных , полученных в результате выполнения запроса, не соответствует буферу sqlfile
и т. д.
Поэтому я и предлагал Вам выполнить запрос в среде СУБД (без Клариона),
и посмотреть какие данные получаются в результате.
Отсюда и начать "пляски с бубном"
Алексей
Мы с Вами как китаец с чукчей разговориваем (ничего личного )
Я спрашиваю про результат выполнения запроса, а Вы отвечаете - да они необходимы.
Начнем сначала:
Ошибка может возникать, в том числе, по причине:На запрос:
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
и т. д.
Поэтому я и предлагал Вам выполнить запрос в среде СУБД (без Клариона),
и посмотреть какие данные получаются в результате.
Отсюда и начать "пляски с бубном"
Алексей
-
- Посетитель
- Сообщения: 49
- Зарегистрирован: 18 Август 2005, 10:16
- Откуда: Пермь
- Контактная информация:
Re: Clarion - PostgreSQL
Ничего не помогло, но в процессе экспериментов вышел на другое решение, которое работает.
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_;
Применим и вариант с одной промежуточной таблицей с выборкой из нескольких таблиц.
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_;
Применим и вариант с одной промежуточной таблицей с выборкой из нескольких таблиц.
С уважением, П.Ялунин (PIT)
-
- ✯ Ветеран ✯
- Сообщения: 1014
- Зарегистрирован: 08 Июль 2005, 6:48
- Откуда: Россия
- Поблагодарили: 1 раз
Clarion - PostgreSQL
Всем привет!
6.3, (ODBC) PostgreSQL 9.5.4
(да, pgSQL увидел "живьем" несколько дней назад)
надо синхронизировать данные файлов (Dat) с данными таблиц на сервере, сгенерил простенькую программку для проверки и перезаписи данных (loop-next, insert|update|delete, вообщем все просто по рабоче-крестьянски и без prop:sql...), но "неожиданно" все медленно , скорость обработки просто удручает, т.к. например на MS SQL все это работало б очень быстрее, но тут надо именно на PostgreSQL.
Есть ли у кого наработки, "волшебные пилюли", или только через скрипты можно ускориться?
6.3, (ODBC) PostgreSQL 9.5.4
(да, pgSQL увидел "живьем" несколько дней назад)
надо синхронизировать данные файлов (Dat) с данными таблиц на сервере, сгенерил простенькую программку для проверки и перезаписи данных (loop-next, insert|update|delete, вообщем все просто по рабоче-крестьянски и без prop:sql...), но "неожиданно" все медленно , скорость обработки просто удручает, т.к. например на MS SQL все это работало б очень быстрее, но тут надо именно на PostgreSQL.
Есть ли у кого наработки, "волшебные пилюли", или только через скрипты можно ускориться?
-
- ✯ Ветеран ✯
- Сообщения: 5006
- Зарегистрирован: 28 Май 2009, 15:54
- Откуда: Москва
- Благодарил (а): 7 раз
- Поблагодарили: 21 раз
Clarion - PostgreSQL
А что именно медленнее? Уже был здесь, кстати, баттл по поводу скорости SQL. Например, нельзя для SQL делать set(File), потом next(File), и т.д.
We are hard at work… for you.
-
- ✯ Ветеран ✯
- Сообщения: 1014
- Зарегистрирован: 08 Июль 2005, 6:48
- Откуда: Россия
- Поблагодарили: 1 раз
Clarion - PostgreSQL
да хз, просто может к новой системе не привык или сам где по коду накосячил, но кажется что пашет медленно - вместо ожидаемых секунд - минуты. поеду домой, подумать надо до завтра, с утра посвежевшим взглядом пройдусь - может взлетит)
-
- ✯ Ветеран ✯
- Сообщения: 1014
- Зарегистрирован: 08 Июль 2005, 6:48
- Откуда: Россия
- Поблагодарили: 1 раз
Clarion - PostgreSQL
посмотрел код, упростил просмотр при отборе "кандидатов" на обработку - залетало)
пошел на автобус
пошел на автобус
-
- ✯ Ветеран ✯
- Сообщения: 1014
- Зарегистрирован: 08 Июль 2005, 6:48
- Откуда: Россия
- Поблагодарили: 1 раз
Clarion - PostgreSQL
всем привет!
решил апнуть - тем, кто утомился с pgadmin 3, посмотрите http://dbeaver.jkiss.org/docs/features/
решил апнуть - тем, кто утомился с pgadmin 3, посмотрите http://dbeaver.jkiss.org/docs/features/
-
- ✯ Ветеран ✯
- Сообщения: 1014
- Зарегистрирован: 08 Июль 2005, 6:48
- Откуда: Россия
- Поблагодарили: 1 раз
Clarion - PostgreSQL
вообщем "велосипед" - начал формировать и отправлять инструкции (insert|update|delete) SQL порциями для обработки сразу больше чем одной записи - стало быстрее
-
- ✯ Ветеран ✯
- Сообщения: 1014
- Зарегистрирован: 08 Июль 2005, 6:48
- Откуда: Россия
- Поблагодарили: 1 раз
Clarion - PostgreSQL
пока такой вопрос у меня образовался, сразу оговорюсь, что тонкостей не знаю, мое дело в этом проекте - записать данные на один сервер pgsql и при необходимости считать на другом.
задача - очень быстро "зеркалировать" схему с кучей табличек между 2 серверами pqsql,
чел, который это обеспечивает, навесил триггеров и когда мои программы пишу на сервер небольшие порции данных, все быстренько обновляется и на другом сервере (<->), но как только порция данных увеличивается - до нескольких десятков тысяч записей, у меня из программы уходят инструкции на 1й сервер за миллисекунды/секунды/иногда за единицы минут (зависит от размера/формата полей в записях, вообще если много идет обновл. данных то в зависимости от формата файлов успешно через prop:sql порциями по 100/200/500 записей за раз отправляется, возможно и большими, но при увеличении размера порции через некоторое время падает скорость отправки, ну и проверять постоянно надо - вдруг "загрубил" и вышел за границы - сервак не примет такой кусман... ) и на 1м сервере все ок, но вот на другом (условно 2м) сервере, чтобы увидеть эти новые данные... приходится идти ставить кофе/выпить его/вымыть посуду/сходить почитать http://forum.clarionlife.net/ , атас вообщем... - по условию надо быстрее все получать на 2м сервере, да и ожидалось что будет ОЧЕНЬ быстро
Чел намекает "у меня все ок", а ты сам виноват - много данных - правь СВОЙ алгоритм и пересылай меньше мусорных данных... Алгоритм-то я вычищу... в очередной раз , но по факту - действительно настолько МЕДЛЕННО идет синхронизация данных между серверами PostgreSQL? или пора ... чела, долго и вдумчиво, что бы он начал шевелиться?
up - порядка 50000 +/- 1000 записей - и всё, "замерзает" надолго...
задача - очень быстро "зеркалировать" схему с кучей табличек между 2 серверами pqsql,
чел, который это обеспечивает, навесил триггеров и когда мои программы пишу на сервер небольшие порции данных, все быстренько обновляется и на другом сервере (<->), но как только порция данных увеличивается - до нескольких десятков тысяч записей, у меня из программы уходят инструкции на 1й сервер за миллисекунды/секунды/иногда за единицы минут (зависит от размера/формата полей в записях, вообще если много идет обновл. данных то в зависимости от формата файлов успешно через prop:sql порциями по 100/200/500 записей за раз отправляется, возможно и большими, но при увеличении размера порции через некоторое время падает скорость отправки, ну и проверять постоянно надо - вдруг "загрубил" и вышел за границы - сервак не примет такой кусман... ) и на 1м сервере все ок, но вот на другом (условно 2м) сервере, чтобы увидеть эти новые данные... приходится идти ставить кофе/выпить его/вымыть посуду/сходить почитать http://forum.clarionlife.net/ , атас вообщем... - по условию надо быстрее все получать на 2м сервере, да и ожидалось что будет ОЧЕНЬ быстро
Чел намекает "у меня все ок", а ты сам виноват - много данных - правь СВОЙ алгоритм и пересылай меньше мусорных данных... Алгоритм-то я вычищу... в очередной раз , но по факту - действительно настолько МЕДЛЕННО идет синхронизация данных между серверами PostgreSQL? или пора ... чела, долго и вдумчиво, что бы он начал шевелиться?
up - порядка 50000 +/- 1000 записей - и всё, "замерзает" надолго...
Последний раз редактировалось Ал 17 Декабрь 2016, 18:30, всего редактировалось 2 раза.