Pervasive + Delphi

[usasacm]

Была такая задача, только Pervasive + C#.
Долго бился чтобы все работало быстро, добавлялись уникальные ИД и еще куча проблем.
Решили все просто, зарегистрировали Галактику как OLE сервер на отдельной машине, потом через Excel вызвали
предварительно написанный фейс (у нас правда не из Excel данные а из DBF) и на этом проблема отошла.

[paparocii]

А сколько у Вас записей в таблице ATRVAL?

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

Все очень медленно... сейчас когда в таблице attrval порядка 1 млн записей или в ttndoc порядка 0,5млн записей все очень медленно,особенно когда нагружен сервер.
convert(wtable) - не использует индексы. А в данных таблицах все индексы составные, например wtable + cdoc в ttndoc - недавно ужасался - по конкретному cdoc запрос выполнялся 10 минут, писец...

никто не пробовал использовать серверную часть - pervasive 11? Возможно проблема "с некорректным отображением типа" решена, и СУБД не "виснет?

[LaaLaa]

Как то проводил тест:

На Pervasive SQL 11 x64, Операционная система Windows 7 x64, Оперативной памяти 4ГБ/
В настройках первасива указано, что он может использовать до 60% памяти.
Таблица Oborot содержит 3.7 миллиона записей.
База создавать новая. Данные закачивались из DBI (позже из DBF),

Запросы выполняю в программе Pervasive Control Center
Меню "File \ New \ SQL Document", а затем меню "SQL \ Execute in Text [Shift+F9]".

Примеры запросов:
1) Запросы
select distinct SchetO from oborot where SchetO like '126'
select distinct SchetO from oborot where SchetO = '126'

выдают
0 rows were affected.

2) Запрос

SELECT sum(o.SumOb), sum(o.Kol) FROM Oborot O WHERE o.SchetO = '126'

выдает
<<<<<<<<<<<<<<<<<<<<<<<<
EXPR_1 EXPR_2
======================== ========================
(Null) (Null)

1 row was affected.

>>>>>>>>>>>>>>>>>>>>>>>>

3) В то время как данные соответствующие значению SchetO = '126' в базе присутствуют
убеждаюсь в этом выполняя запросы
select distinct SchetO from oborot where SchetO like '12%'
SELECT sum(o.SumOb), sum(o.Kol) FROM Oborot O WHERE o.SchetO like '12%' group by o.SchetO
SELECT sum(o.SumOb), sum(o.Kol) FROM Oborot O WHERE ltrim(o.SchetO) = '126'

Правда такие запросы работают очень долго от (40 мин до нескольких часов) но выдают правильный и ожидаемый результат (если конечно дождаться ответа).

4) На более маленькой таблице подобные запросы работают нормально

select distinct schet from buhschet where schet = '126'
select distinct schet, subsch from buhschet where schet like '123'

выдают правильный и ожидаемый результат.

Результаты этого теста позже были повторены на другом компьютере также на вновь созданной большой БД. Всякие попытки починить индексы, таблицы и т.п. не дали устойчивый результат. У меня сложилось впечатление, что первасив вообще в принципе работает только тогда когда индексы вместе сданными умещаются в ОЗУ. При бОльших объемах он работает не устойчиво.

[Syte]

никто не пробовал использовать серверную часть - pervasive 11? Возможно проблема "с некорректным отображением типа" решена, и СУБД не "виснет?

Я попробую на выходных 21-22-го
у самого такая проблема, очень надеюсь, что она решена в 11-й версии.
Во всяком случае разработчик об этом заявлял.

[LaaLaa]

Смысла нет с первасивом возится.

[Syte]

Смысла нет с первасивом возится.

Это смотря сколько лицензий куплено.

Хотя если Галактика ломаная, то да, смысла нет.

[Начинающий путь]

Как указать правильную сортировку в ORDER для текстовых полей в первасиве дата манагер, в таком, например запросе:

select a.Fio from persons a order by a.fio

[Syte]

а правильная - это какая?

[Начинающий путь]

а правильная - это какая?

По афавиту, а то сортирует сначала буква В, потом Б...

Да, база лежит в 866 кодировке.

[Syte]

не важно в какой кодировке, порядок символов задается как раз ею.
Не знаю, в чем у Вас проблема но у меня при таких же составляющих, включая запрос, всё сортируется правильно.
то есть PSQL DM плюс БД Галактики в 866 кодировке

[Начинающий путь]

Всё, разобрался. Нет индекса в Persons, начинающегося с FIO...