forum.clarionlife.net

Кто и как решает проблему?
Я думаю, что этот баг в драйвере C6 для MSSQL.

Опишу проблему для тех кто не в танке.

1. Создаем Таблицу с драйвером MSSQL, где есть уникальный автоувеличивающийся ключ.
2. Заполняем таблизу 2-3мя записями.
3 Создаем Окно Со списком показывающий содержание созданой табицы, но не используем wizard.
4 Компилим и запускаем.
5 листаем лист стрелочками на клавиатуре и видим как размножаются в этом списке одинаковые записи.

6. Лезем в хелп в топик об особенностях использования odbc-драйверов и читаем там, что для адекватной работы необходим доступ по уникальному ключу.

P.S. 99% ошибок, о которых говорят "это глюк клаши" - следствие кривых ручек и/или нежелания ковырятся в хелпе - сужу по своему опыту.

На самом деле это очень старый глюк, который встречался у меня еще в ДОС на модели данных кларион(.dat).В силу так и не выясненных до конца причин иногда на маленьком файле происходило
"размножение" записей в бровзе. По мере заполнения файла это глюк исчезал сам собой.Так что это вряд ли связано с ODBC драйвером MSSQL.Попробуй пересоздвать таблицу средствами MSSQL и импортируй ее описание в словарь.

softcreator писал(а): P.S. 99% ошибок, о которых говорят "это глюк клаши" - следствие кривых ручек и/или нежелания ковырятся в хелпе - сужу по своему опыту.

Да?
Почему же тогда в Delphi такого глюка нет?
Куда уж уникальней Ключ, который Autoincremented!
К примеру есть таблица: Types
В ней поля: ID - Long, Name - CSTRING (21)
Ключ: IDKEY - ID (ASCENDING) [Unique, Primary, Autonumber, Case sensitive]
softcreator, что посоветуеш? Добавить еще и Name в этот ключ?

lsgsoftware
Тоже вариант.
Но, 26 таблиц с полями от 3 до 83! пересоздавать в MSSQL только, для того, чтобы проверить "вдруг заработает" - это не выход.

Вам же русским языком ответили -УНИКАЛЬНЫЙ КЛЮЧ. Delphi здесь совершенно не причем, там используються совешенно другие технологии доступа к данным - CDO, ADO и так далее.

это опять таки FAQ-овый вопрос
здесь немного есть:
http://mavcla.arsis.ru/rules.htm

Caня
Еще раз - наличия индекса в таблице мало. Нужен ДОСТУП по уникальному индексу. А в твоем браузе наверняка стоит доступ либо вообще без ключа, либо по неуникальному ключу.

И при чем тут делфи? Если я работаю через ODBC напрямую - то мне фиолетово наличие ключей (это головняк самого сиквела и проблема создателя структуры таблиц - если он не предусмотрел всех нужных мне индексов, которые мне могут потребоваться).

Еще раз - настоятельно рекомендую не искать сразу же причину пробемы в клаше. У подавляющего большиства кларионистов причина их проблем в банальном незнании/непонимании того, что они делают.
И правильный вопрос - не "это глюк клаши!!!", а "что я делаю не так?".

P.S. Не будет выходить каменный цветок - шли скрипт таблицы и пример приложения.

Проблема не нова, все кто работает MSSQL наверняка с ней сталкивался. Дело в том, что NEXT(View) при формировании Browse может возвращать errorcode() при достижении окончания файла, а может и не возвращать, получая одну и ту же запись неоднократно.
Хотя может для SQL окончание файла и неопределено в том смысле, как в файл-серверных драйверах ).
Вообщем сам помучился в свое время. Насколько я знаю, решается пока только одним способом - все отображения в Browse (как основное так и дополнительные) должны строится по уникальным ключам, соответственно проще всего добавить в эти ключи поле Num (ID), которое соответственно Autoincrement.
Удачи.

Дело не неком конце файла - его для сиквела вообще нет, ибо нет физического порядка следования записей - в терминах tps к примеру. Браузер по своей логике нуждается в постоянном перепозиционировании. И может позиционироваться только используя уникальное сочетание полей ключа доступа - только это позволит верно работать скруллингу. Для сиквела не применимо понятие физический номер записи, а для любого десктопного формата любой POSITION в конце концов выливается в определение именно номера записи, поэтому там нет жесткого требования уникальности ключа доступа. При использовании сиквела POSITION выливается в формирование набора полей и если значения этих полей не дают уникальной идентификации записи - происходят всякие разности, в том числе и дублирование записей.

В самую точку...

Andrew Listiev,

Вам же русским языком ответили -УНИКАЛЬНЫЙ КЛЮЧ

Извиняюсь, что на английском написал

Ключ: IDKEY - ID (ASCENDING) [Unique, Primary, Autonumber, Case sensitive]

StillZero, спасибо за ссылку! Лаконично и полезно. Правда, я не нашел 4-е правило. Оно очем?
softcreator и ru_alex, спасибо!
Вы так детально объяснили проблему, но решения для конкретно описанной таблицы так и не предложили.
Я новичек в Кларионе, просто это условие заказчика. Сам я из Delphi+Postgress под виндами и Perl+Postgress под линуксом, и некоторые аспекты в Кларионе+MSSQL мне непонятны, в силу того, что я пытаюсь думать о Кларионе с позиции Дельфи.
Причина проблемы мне ясна. Как вы с ней справляетеь?
см. описание таблицы выше.

Мдя... кажись все уже разжевали - и рекомендации дали и теорию подвели...
я же писал: не получится - шли скрипт создания таблицы, тестовое приложение + словарь в личное мыло vadim@jrc.com.ua

Короче, либо меняй ключи в таблице, по которым отображаешь Browse, либо делай отображение по своему IDKEY, все будет ок.