forum.clarionlife.net

2 таблицы связанные реляцией, обе отображаються в одном окне и при перемещении через browse по первой таблице(Т1) показываються связанные записи второй(Т2). Обе таблицы были файловые, tps. Сейчас (Т2) перенес в MS SQL и заметил что при перемещении по записям (Т1) данные из (Т2) стали отображаться с заметной задержкой.
В процедуре где созданы browse ничего не менял, менял только в словарике тип драйвера (Т2) на MS SQL и типы полей привел в соответствие с MS SQL. Clarion 5.5EE. Шаблоны использую Clarion, не ABC.
В чем может быть причина?

Хотелось бы видеть описание БД в словаре и на сервере. Менять только тип драйвера и типы полей абсолютно недостаточно.
Возможно, в Словаре есть связь по ключику, а в базе данных - нет. Или в таблицах нет первичных ключей.
Ну и, конечно, пустить трассировку, посмотреть, что там тормозит...

в кларионе вот так в sql

А нафига в SQL БД столько ключей ? Достаточно одного. В 1-й таблице по ID, во второй ID + какой-нибудь ID1 для уникальности.
Связь между таблицами естественно по ID.
Цитата.
Не создавайте ненужные индексы. Помните, каждый индекс ускоряя выборку данных, замедляет добавление/изменение/удаление записей.

На первый взгляд:
В Кларионе у таблицы нет первичного ключа (Primary). А надо проставить, для SQL - драйверов Клариона это важно, по нему будет определяться текущее положение записи. Остальные ключики не уникальные - не сильно понятно, как по ним идёт фильтрация. В Browse крайне желательно, чтобы ключ для Browse был уникален, иначе будут всякие странные глюки с листанием. В ABC можно добавить поле ID к порядку сортировки, как в Legacy - не знаю. Ну и, конечно, пустить с трассировкой, посмотреть, на чём тормоза происходят.

А нафига в SQL БД столько ключей ? Достаточно одного.

Это разве "Столько"? Если база приличная, то и 20 ключей нормально. Реально ключ связан с Constraint - на каждую связку по ключу, а то и по два.

Для одной таблицы ???

Для данного случая не вижу смысла делать индексы по полям типа STRING, CSTRING и DATE. А SELECT ... ORDER BY для чего ?

для описания реляции в словаре вроде как нужен ключ - ByIPNum и затем в browse для фильтрации записей
ключ уникальный все же есть - ByID
но он в этом browse не используется

select-ы в данной процедуре не использую, старался минимальными изменениями перейти на ms sql, т.е. нативными средствами клариона
в данном случае это шаблон browse

gromov писал(а): 31 Май 2017, 11:12 А нафига в SQL БД столько ключей ? Достаточно одного. В 1-й таблице по ID, во второй ID + какой-нибудь ID1 для уникальности.
Связь между таблицами естественно по ID.
Цитата.
Не создавайте ненужные индексы. Помните, каждый индекс ускоряя выборку данных, замедляет добавление/изменение/удаление записей.

они унаследованы от старой tps таблицы, потом можно будет удалить

я вот подумал, может мне эту зависимую browse удалить и создать заново, может все ж есть какая привязка в шаблонах к файл-драйверу?

alex881 писал(а): 31 Май 2017, 11:59 я вот подумал, может мне эту зависимую browse удалить и создать заново, может все ж есть какая привязка в шаблонах к файл-драйверу?

не, не помогло ;-(

А зачем связанные таблицы в разных системах? Никогда не видел, честно! Возможно в этом косяк, идёт постоянный переконнект и фиг знает ещё что.

MS SQL по сравнению с локальным tps заметно медленнее работает, это не новость, особенно штатные шаблоны, которые под SQL не заточены

kreator писал(а): 31 Май 2017, 12:20 А зачем связанные таблицы в разных системах? Никогда не видел, честно! Возможно в этом косяк, идёт постоянный переконнект и фиг знает ещё что.

не понял вопроса

RaFaeL писал(а): 31 Май 2017, 12:29 MS SQL по сравнению с локальным tps заметно медленнее работает, это не новость, особенно штатные шаблоны, которые под SQL не заточены

мож я тогда и зря заморочился......